Dotneteers.net

A Designer-friendly Approach to MVVM

vbandi — Fri, 12 Mar 2010 14:54:08 GMT

My new article, “A Designer-friendly Approach to MVVM” is up at Silverlight Show. Here is the intro:

“If you work with Silverlight or WPF, you have probably met the phrase “MVVM”. Almost everyone who is anyone in the WPF / Silverlight scene has their own MVVM framework, and their own way of explaining and teaching MVVM. Scary terms like IoC, Dependency Injection, Commanding Frameworks, Event Aggregators, Unit Testing, etc just roll off the tongue of the MVVM experts. This is one of the reasons why MVVM is intimidating for a lot of people. Still, you can create perfectly valid MVVM applications without even knowing what those terms mean. This post will show you my approach to MVVM, which is hopefully simple enough to get you started.”

So, head over to Silverlight Show, and let me know what you think!

Part 2 of my Blend Screencast Series is Online

vbandi — Fri, 05 Mar 2010 17:07:02 GMT

The second part of my screencast series “Transforming an Ugly Duckling into a Graceful Swan With Expression Blend and Silverlight - Part 2 Intro Animation” is now online at SilverlightShow.net. In this part, I am going to add some bling to the app – namely the Intro animation, the ability to skip it, and to replay it. The Intro animation itself is not created with Silverlight, so I will just use it as a video. This part takes heavy use of Visual States, Behaviors and Easings.

To see the article and the associated screencast, go to SilverlightShow.Net.

VS 2010 Package Development – Chapter 1: Visual Studio Packages

inovak — Tue, 02 Mar 2010 12:13:03 GMT

I have spent a lot of time with preparing a book about Visual Studio Extensibility, focusing on Visual Studio Package Development. I have made proposals for several book publishers, but I did not manage to get a contract, most of them found such a book is not profitable. I decided to share the four chapters of the book that I’ve already written. They are the followings:

Chapter 1: Visual Studio Packages
Chapter 2: Commands, Menus and Toolbars
Chapter 3: Window Management and Tool Windows
Chapter 4: Services

I hope, you will find these chapters useful.

The majority of Visual Studio’s functions you use in your everyday work (such as programming languages, editors, designers and debuggers) are provided by Visual Studio Integration Packages, or shortly by packages. Some call them VSIP packages but the VSIP acronym is overloaded: while the first two letters means “Visual Studio” the last two may mean either “Integration Package” or “Industry Partner” and unfortunately both terms are frequently used. To avoid ambiguity hereinafter you’ll meet the term package or VSPackage.

Developing packages means you can extend Visual Studio on the same way as its developer team at Microsoft. Adding new functions through packages is actually programming a new part of Visual Studio just like if you were the member of the team. You can use the full power and integrate any functionality you miss from the IDE!

In this chapter you will create a very simple package called FirstLook to get a feeling that first steps are easy. Then you’ll learn the basic concepts behind packages and dive into the FirstLook project’s structure and source code to have a closer look at the implementation of those concepts. At the end of this chapter you’ll be familiar with the following:

Building a package with the VSPackage Wizard
The idea of a package
The on-demand package loading mechanism and the idea of package siting
Registration of packages and information stored in the registry
The Visual Studio Experimental Hive and using it for debugging packages
The package build process
Deploying VSPackages

This chapter will not teach you how to build a specific functionality into a package and does not cover the API used to develop packages. The focus is on understanding the concepts, architectural considerations behind VSPackages to let you take a look behind the scenes and get acquainted with package mechanisms. These concepts will be very useful when you are about creating your own packages.

Building a Simple Package

There are a few important concepts to understand if you want to develop a package. In order treat them in the right context you build a very simple functional package to touch the surface of those concepts and then jump into the details.

A Visual Studio package is a class library containing the types responsible for the package infrastructure and functionality. In order Visual Studio recognize the compiled class library as package, encapsulated types should have specific metadata information and some additional steps are required after compilation. So, even if you could start building a package from an empty class library, it is much easier to use the VSPackage Wizard installed with Visual Studio SDK.

Start a new project with the File|New|Project command. The IDE displays the New File dialog to select the desired project type. You can find the Visual Studio Integration Package project type under the Other Project Types category in the Extensibility folder as Figure 1 illustrates.

Figure 1: The New Project dialog with the Extensibility project types

Should you not find this project type or many other project types in the Extensibility folder means that Visual Studio SDK is not — or not properly — installed on your machine. Install it according to the setup notes in order to go on with building the package.

Give the FirstLook name to the package in order to be able to follow code details later in this chapter. Clicking the OK button starts the Visual Studio Integration Package Wizard (henceforward VSPackage Wizard is used, it is shorter) which welcomes you with the dialog in Figure 2.

Figure 2: The Welcome page of the VSPackage Wizard

Click the Next button to go on specifying the package parameters and you get to the Select a Programming Language page of the wizard as Figure 3 shows.

Figure 3: VSPackage Wizard lets you select the programming language

As it was mentioned earlier you create the code in C#. Packages are strongly named assemblies, so you need to sign the class library assembly with a key. For this project the wizard creates the signing key. Click Next and you get to the Basic VSPackage Information page as Figure 4 shows.

Figure 4: The wizard asks for the basic package information

The information you provide here will be used in the source code generated for the package and will be displayed in the Visual Studio About dialog. The Company name will be used in the namespace of generated types as well as VSPackage name which also names the class representing the package in code. VSPackage version is additional information to give a way for distinguishing separate package releases.

Text typed in the Detailed information field will be displayed in the About dialog and can supply the user with more information about what the package does.

When you click the Next button the wizard moves you to the VSPackage Options page — as can be seen in Figure 5 — to set a few more code generation options.

Figure 5: You can select a few code generation options

In this sample you are going to create only a menu command that pops up a message on the screen, so set the Menu Command option. Should you select the other two options the VSPackage Wizard would create some more code for a simple tool window or a rich text editor. Please, let those options remain unchecked. With the Next button the wizard goes to the page where we can specify a few details about the menu command to create. This page is shown in Figure 6.

Figure 6: Command options are specified here

The command will be added to the Tools menu of Visual Studio, in Command name you can specify the text to be displayed for the menu item. According to the internal command handling architecture each command has an identifier. The Command ID field supplies a name for this identifier and VSPackage Wizard will generate an ID value behind this name. With clicking Next the wizard moves to the Test Project Options page as shown in Figure 7.

Figure 7: VSPackage Wizard asks for test project options

The wizard can create unit test for the package which check if its functional units work properly. The wizard also can create an integration test project for you, in which packages are tested within the context of a Visual Studio instance.

For the sake of simplicity here you do not create any tests, so clear the options — by default both are checked. Now you have set all parameters the wizard uses to generate the package project, click on the Finish button.

In a few seconds the wizard generates the package project ready to build and run. Taste the pudding you have just cooked! With the Build ð Rebuild Solution function you can compile the package and carry out all other steps required to run the package with Visual Studio. So rebuild the project and start with Ctrl + F5 (Debug|Start Without Debugging).

You might be surprised as a new instance of Visual Studio is started with “Experimental Instance” in its window caption.

Note: If this is the first time you have started the Experimental Instance, the Choose Default Environment Settings dialog appears just like when you first time launch Visual Studio after installation.

This is an instance of Visual Studio that hosts the FirstLook package — later you’re going to learn the concept behind. The menu command implemented by this freshly generated package can be seen in the Tools menu as Figure 8 shows it.

Figure 8: The menu command item appears in the Tools menu

When you click the Simple Message command, it pops up a message box telling you it was displayed from the FirstLook package.

The package also registered some branding information that can be seen in the Help|About dialog as Figure 9 shows.

Figure 9: Branding information of the FirstLook package

Nothing call tell more about your VSPackage than its source code. But before deep-diving into it, let’s treat important concepts about packages.

Concepts behind Visual Studio Packages

A VSPackage is the principal architectural unit of Visual Studio. As you already know, Visual Studio IDE itself is the Shell hosting a set of VSPackages working together with each other and with the Shell. The basic responsibility of a package is to provide a common container for extensibility objects. So, a VSPackage is a software module that is a unit not only from architectural point of view but also from deployment, security and licensing aspects.

Developers — including the developers of Visual Studio — create VSPackages to provide some extension to the VS IDE and group them into modules according to their functionality. These extensions can be:

Services. These are software objects that offer functionality for other objects in the same package or even for other packages. For example, the C# Language Service (as its name also tells) is a service.
User interface elements. Menus, toolbars, and windows can be used by developers to initiate some actions in the user interface, interact with, display messages, information and figures, and so on.
Editors. During development you write and modify program text to create applications. This task is the responsibility of an editor. Visual Studio 2010 has its own core text editor and you can extend it or even create your own editors.
Designers. Application creation is not just simply a text-typing activity. There are many visual tools known as designers that allow an alternative representation and design of modules, components, parts or even full applications. Well-known examples are the Windows Forms designer, The WPF Forms designer, the ASP.NET page designer or the Data Table designer.
Projects. When developing applications you generally work with a large number of files. A project is an organization of source files and resources. A project not just simply stores these files but also defines operations with them, allows building, debugging and deploying the products created from source files.

It is natural in .NET that you can divide your functional units into separate assemblies where consumer assemblies will reference other service assemblies. The same principle works for VSPackages: an assembly containing a package can reference other assemblies that may contain not just helper types but even extensibility object types.

An assembly — as the smallest physical deployment unit in .NET — may contain more than one VSPackage. Although generally only one package is encapsulated in an assembly, you may have many reasons to group more packages in one assembly — including deployment considerations.

The Package Load Key

The previous versions of Visual Studio checked the package before loading them into the process space of the Shell. Any VSPackage should have been “sealed” with a so-called Package Load Key (PLK) and this key was verified during package load time. PLK was not a digital signature or a full hash, because it was calculated from a few information fields in the package. PLK could have been requested from Microsoft through a webpage: the developer specified a few well-defined attributes of the package and some logic calculated the PLK value. This value was embedded as a resource into the assembly representing the package.

Every time the package was loaded, the Shell checked the PLK against the package attributes it had been created from. Should have been this check fail, the Shell would have refused loading the package. This PLK mechanism did not mean that a developer had to request a new PLK for each package modification. While no basic information the PLK had been generated from was changed, the package continued to load.

Although this concept had been seemed useful, in the real life in had no real advantage. To be honest, in most of the cases it was the root cause of deployment issues, in many scenarios it raised more problems than it solved.

In the new Visual Studio 2010 the Shell does not use the Package Load Key to check packages before loading them into the memory.

On-demand Loading of Packages

You can imagine that complex packages like the C#, VB, F# or C++ languages with all of their “accessories” could consume many system resources by terms of memory and CPU. If you do not use them they do not press the CPU, but they might use the memory if they sit within the Visual Studio process space. If you create a project using F# you actually do not need services belonging to other languages, so why to load them into the memory at all?

The architects of Visual Studio implemented the package load mechanism so that packages are loaded into the memory at the first time when an event requiring the presence of the package is raised. These events can be one of the followings:

Command activation. The user (or some running code) activates a menu or toolbar command (or even a command that cannot be accessed from UI) served by a package which has not been loaded yet. It does not matter if the user has clicked on a menu item or the running code has activated it with a “virtual click” the result is the same.
Object or service request. The Shell is about to use an object or a service in a package not loaded yet. For example a tool window should be displayed or a service function is about to be executed.
Context change. The Shell can enter into certain user interface contexts. For example, when you start debugging a project, the Shell enters into the Debugging context. When a solution with a single project is loaded, the Shell enters into the SolutionHasSingleProject context. You can declare that a package should be loaded as the Shell enters in a certain context. Visual Studio has a few predefined contexts, but you can also define your own ones.

So, if you do not need a package during the whole IDE session, it does not consume the memory at all. Should you click on a menu item activating a command sitting in a package which has not been loaded yet the IDE will immediately load and initialize it. Should you ask for a tool window in a package not in the memory yet, the IDE will start loading it.

Binding package loading with a context change is generally required where your package want to subscribe for events raised in Visual Studio. You cannot bind the event either to command activation or object or service requests, because in order your package could work you have to subscribe to events. The code to create subscriptions is generally put into the initialization code. But you cannot run any code belonging to a package while it is not loaded into the memory! In this case you declare that the best context (the latest possible) to load the package. If your package logic requires, you can specify the NoSolutionExists context. Visual Studio enters into this context immediately when the Shell is loaded and ready to function, so packages bound to this context load at Visual Studio startup time.

Note: Be frugal with system resources if you have to load a package at Visual Studio startup time. Allocate only resources that are indispensable to carry out the required initialization at startup time.

Package Siting

When you develop a package it is an independent piece of code. When it is loaded into Visual Studio it becomes an organic part of the IDE:

Your package can access services and objects provided by the Shell and other packages.
The Shell and other packages can access the objects and services you proffer them.

The process of making a package physically integrated into the Shell is called siting. While the package is not sited, its functions cannot be used from outside. From the same reason the package can be only partially initialized, because it cannot touch any objects or services through the Shell. As soon as the package gets sited, it is ready to finish its initialization and be fully functional. Siting happens when Visual Studio loads the package.

The object type representing your package must implement an interface called IVsPackage (you are going to learn details later in this chapter) and must have a default constructor.

Loading a package contains the following steps:

The Shell creates an instance of the object type representing your package by invoking its default constructor.
The Shell calls the SetSite method of the object instance — IVsPackage defines this method — and passes a so-called service provider instance which can be used by the package to query objects in order to access services implemented by the Shell or other packages.
The Shell allows your package to finish its initialization. In the first step during the construction call the service object did not have any contact with the Shell. After siting all initialization steps invoking Shell services can be carried out.

Although siting physically integrates your package functionally with Visual Studio, functional integration may require some additional — and sometimes complex — steps depending on what your package is intended to do.

Package Registration

Visual Studio must keep track of packages in order to load and use them. Of course, the most flexible would be some kind of discovery where the Shell can look around only in the file system to guess out which entities represent packages. The .NET framework supports and intensively uses metadata (attributes) that can represent the information you can use for this purpose. You can even load an assembly so that only the metadata part is read from the file system and put into the memory. Although you can imagine this mechanism could work, it is not used by the Shell in this way.

The reason is that the roots of Visual Studio go back to the COM era. Packages are COM objects and can be created not only in managed code but also in native code using the Win32 API with any language including C++, Delphi and others. So, not surprisingly Visual Studio uses the registry to keep information about packages.

Although the registry is used to store configuration information about Visual Studio settings, developers and package users are not bothered with registration issues. The new deployment mechanism (through VSIX files) implemented in Visual Studio 2010 takes away this task. When Visual Studio is started, its discovery mechanism collects the information to be entered into the registry and does all the registration process on the fly. Developers perceive they do installation only by copying files and this resembles to the great mechanism we are using with the .NET Framework.

Package Information in the Registry

Packages are loaded into the memory on-demand. To effectively use this approach, Visual Studio stores the registration information about packages in a way so that this information could be accessed from the direction of objects to be used. For example, one kind of object that could trigger package loading is a tool window. A tool window has its own identity. When it is about to be created in order to be displayed, Visual Studio turns into the registry and addresses the corresponding key with the tool window identity. Under that key there is information stored about the identity of the package owning and implementing the tool window. Using this identity Visual Studio finds the registry key containing the package information and loads the package into the memory accordingly. The identity of packages and objects is represented by a GUID.

Figure 10 shows a few registry keys that store package-related information for Visual Studio.

Figure 10: Package and object information in the registry

Assume that Visual Studio is about to create a service instance. It uses the Services registry key and according to the service identity it finds the package. Figure 11 illustrates the service key of the Class Designer Service. At the left side you can see the subkey named by the GUID identifying the service. At the right side you see the corresponding package ID in the default value under the service key.

Figure 11: Service information in the registry

Visual Studio uses the same approach to find owner packages for any other objects.

There is one important thing to treat about package information in the registry. Packages can add their own user interface items to the Visual Studio IDE in form of menus and toolbars. If this UI information were created during the package initialization time, Visual Studio would need to load the package at startup time in order to present the package-dependent UI to the users. This approach would demolish the whole concept of on-demand loading.

Instead, the package uses a declarative way to define the user interface that should be displayed in the IDE at startup time. This information is encapsulated into the package assembly as an embedded resource. During the registration process Visual Studio extracts this resource information and merges it with its standard menus. Each user interface element — the commands they represent — is associated with the identity (GUID) of the owner package, so the Shell knows which package to load when a command is activated.

Visual Studio Experimental Instance

When you started the FirstLook package a new instance of Visual Studio was launched with the “Experimental Instance” text in its caption. What is that Visual Studio instance and how did it get to the computer?

Visual Studio Experimental Instance is a test bed to run and debug Visual Studio packages during the development and test phase. It is not a new installation of Visual Studio. It is the same devenv.exe file you use normally. But why you need it?

As it’s been mentioned earlier the package is registered — information is written into the system registry — in order it could integrate with Visual Studio. Every time you build and run a package some information goes into the registry. When you modify the package it might affect also the information in the registry. You can imagine what an unexpected confusion it can lead that you always modify the registry under the Visual Studio instance you actually use to develop and debug a package? What if your package does not work or even worse it prevents Visual Studio start correctly or even causes a crash? How would you fix the pollution of registry?

That is the point when Visual Studio Experimental Instance comes into the picture. The Experimental Instance is simply another instance of Visual Studio that picks up its settings from a different place — including configuration files and registry keys.

The devenv.exe keeps its configuration settings in the system registry in the CURRENT_USER hive under the Software\Microsoft\VisualStudio\10.0_Config key. When Visual Studio runs it reads out the configuration information from these keys by default. With the /rootsuffix command line parameters the root key used by devenv.exe can be changed.

The VSPackage Wizard sets up the package project so that the devenv.exe uses the /rootsuffix Exp command line parameter when running or debugging the package. By doing it so devenv.exe will use the Software\Microsoft\VisualStudio\10.0Exp_Config registry key under the CURRENT_USER registry hive. So running the package with the Start Debugging (F5) or Start Without Debugging (Ctrl+F5) functions will launch the Visual Studio Experimental Instance using this registry key.

The build process of a package copies the package binaries and the so-called VSIX manifest information to a well-known location under the current user’s application data folder. When the Experimental Hive starts, it discovers the package in the folder and uses the information found there to enter the package information into the registry key consumed by the Experimental Instance.

Using the Experimental Instance prevents you polluting the registry of the Visual Studio instance used for the normal development process. However, making mistakes, recompilations and faulty package registrations does not prevent putting junk or leaving orphaned information in the Experimental Instance registry. Making an appropriate cleanup could be very complex and dangerous if you would do it by delving in the registry.

Cleaning up packages from the Experimental Instance’s registry is quite easy! The Visual Studio SDK installs the CreateExpInstance.exe utility and adds it to the Visual Studio 2010 SDK menu items under the Tools folder with the name “Reset the Microsoft Visual Studio 2010 Experimental Instance”. Running this utility will reset the registry key belonging to the Experimental Hive to the state after the installation of VS SDK.

Note: If you develop Visual Studio packages you can get into situations several times where your package which worked before seems suddenly stop working. In majority of these cases the cause is the pollution of Visual Studio registry. There can be many orphaned objects in the registry as a result of continuous modification and rebuild of packages, and that can cause problems. If you run in such a situation, reset the Experimental Instance and then build your package with the Rebuild All function of Visual Studio. This procedure often helps.

Diving into the Package Source Code

You have already created a FirstLook project with the VSPackage wizard and by now you have a good overview about the basic concepts behind packages. Now we go into details and look how those concepts and ideas are reflected in the source code.

When the VSPackage Wizard generated the code according to the parameters we specified on the wizard pages, it made a lot of work at the background. The wizard carried out the following activities:

Generation of a class library project in C#.
Adding references to this project for the interoperability assemblies required to access Visual Studio functionality.
Creating resources used by the package and other resources used by the registration process.
Adding new MSBuild targets to the project to support the build and registration process of the package.
Generation of types responsible for implementing the package functionality.
Setting up the debug properties of the project to start Visual Studio Experimental Instance.

Table 1 summarizes the source files in the FirstLook project.

Table 1: FirstLook source files generated by the VSPackage wizard

Source File	Description
source.extension.vsixmanifest	This is the so-called VSIX manifest file which plays vital role in the discovery and registration mechanism of Visual Studio extensions.
FirstLook.vsct	The so-called command table file storing the definition of the menus and commands to be merged into the Visual Studio IDE during the registration process.
FirstLookPackage.cs	Class implementing the simple functionality of the package.
GlobalSupressions.cs	Attributes used to suppress messages coming from the static code analysis.
Guids.cs	GUID values used to identify the package and command objects within the package.
Key.snk	Signing key used to generate the strong name for the package assembly.
PkgCmdID.cs	Constants for identifying command values.
Resources.resx	Resource file to store your functional package resources — resources you use according to the functions you implement in the package.
VSPackage.resx	Resource file to store package infrastructure resources — those resources which are used by Visual Studio to integrate your package into the IDE.

The wizard added several assemblies to the class library project. Table 2 summarizes their roles. Their names start with the Microsoft.VisualStudio, this prefix is omitted in the table for the sake of clarity.

Table 2: Interoperability assembly references in the project

Source File	Description
~.Shell.Interop	This assembly defines several hundreds of core interoperability types (interfaces, structures, enumerations, classes, etc.).
~.Shell.Interop.8.0, ~.Shell.Interop.9.0 and ~.Shell.Interop.10.0	There are COM types new in VS 2005, VS 2008 and VS 2010 IDEs. The interoperability wrappers of them are defined in these assemblies where the 8.0 suffix is for VS 2005, the 9.0 suffix for VS 2008 while the 10.0 suffix for VS 2010.
~.Shell.Interop.Immutable.10.0	A few abstract and enumeration types used for package registration attributes.
~.OLE.Interop	There are a few hundred of standard OLE types and interfaces. This assembly provides wrapper types for them.
~.Shell.9.0	The core types of the Managed Package Framework. There is a separate version for VS 2008 with the 9.0 suffix. If you work with VS 2008, you should use this assembly.
~.TextManager.Interop	Interoperability assembly with wrapper types to access text editor and text management functionality. Although this assembly is referenced by the project, it is not used in the package you’ve created.

All assemblies having Interop in their names contain only proxy type definitions to access the core Visual Studio COM service interface and object types.

Package Type Definition

Now, let’s see the source code of the package! The wizard added many useful comments to the generated source files. In the code extracts listed here those commands are cut out to make the listings shorter and improve the readability of the code. The indentation has also been changed a bit for the same purpose.

Listing 1 shows the source code of the most important file in our project named FirstLookPackage.cs. This file implements the type representing our package:

Listing 1: FirstLookPackage.cs

 using System;
using System.ComponentModel.Design;
using System.Diagnostics;
using System.Globalization;
using System.Runtime.InteropServices;
using Microsoft.VisualStudio.Shell;
using Microsoft.VisualStudio.Shell.Interop;
 
namespace DeepDiver.FirstLook
{
  [PackageRegistration(UseManagedResourcesOnly = true)]
  [InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
  [ProvideMenuResource("Menus.ctmenu", 1)]
  [Guid(GuidList.guidFirstLookPkgString)]
  public sealed class FirstLookPackage : Package
  {
    public FirstLookPackage()
    {
      Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering constructor for: {0}", this.ToString()));
    }
 
    protected override void Initialize()
    {
      Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
      base.Initialize();
 
      // Add our command handlers for menu (commands must exist in the .vsct file)
      OleMenuCommandService mcs = GetService(typeof(IMenuCommandService)) as OleMenuCommandService;
      if (null != mcs)
      {
        // Create the command for the menu item.
        CommandID menuCommandID = new CommandID(GuidList.guidFirstLookCmdSet, (int)PkgCmdIDList.cmdidShowMyMessage);
        MenuCommand menuItem = new MenuCommand(MenuItemCallback, menuCommandID);
        mcs.AddCommand(menuItem);
      }
    }
 
    private void MenuItemCallback(object sender, EventArgs e)
    {
      // Show a Message Box to prove we were here
      IVsUIShell uiShell = (IVsUIShell)GetService(typeof(SVsUIShell));
      Guid clsid = Guid.Empty;
      int result;
      Microsoft.VisualStudio.ErrorHandler.ThrowOnFailure(uiShell.ShowMessageBox(
                 0,
                 ref clsid,
                 "FirstLook",
                 string.Format(CultureInfo.CurrentCulture, "Inside {0}.MenuItemCallback()", this.ToString()),
                 string.Empty,
                 0,
                 OLEMSGBUTTON.OLEMSGBUTTON_OK,
                 OLEMSGDEFBUTTON.OLEMSGDEFBUTTON_FIRST,
                 OLEMSGICON.OLEMSGICON_INFO,
                 0,        // false
                 out result));
    }
  }
}
 

The FirstLookPackage class becomes a working package by inheriting the behavior defined in the Package class of the Microsoft.VisualStudio.Shell namespace and by using the attributes decorating the class definition.

The Package base class implements the IVsPackage interface that is required by Visual Studio in order to take an object into account as a package. This interface provides a few methods managing the lifecycle of a package and also offers methods to access package related objects like tool windows, options pages, and automation objects. One of the most important of them is the SetSite method having the following signature:

 int SetSite(IServiceProvider psp);
 

Visual Studio calls this method immediately after the package has been instantiated by its default constructor. The psp parameter is an instance of System.IServiceProvider and this object is the key in keeping contact between the package and the IDE: any time the package requests a service object from its context—from the IDE—the psp instance is used at the back, however, the implementation of Package hides it from our eyes.

The overridden Initialize method is called after the package has been successfully sited. This method has to do all the initialization steps that require access to services provided by the Shell or other packages. Should you move this code to the package constructor you would get a NullReferenceException because at that point all attempts to access the Shell would fail as the package is not sited yet and actually has no contact with any shell objects.

The package constructor should do only inexpensive initialization that you would put normally to a constructor. Any other kind of initialization activities should be put to the overridden Initialize method. If you have some other expensive initialization activity that can be postponed, you should do them right when there’s no more time to delay them.

In this case the Initialize method binds the single menu command provided by the FirstLookPackage with its event handler method called MenuItemCallback:

 protected override void Initialize()
{
  Trace.WriteLine(string.Format(CultureInfo.CurrentCulture, "Entering Initialize() of: {0}", this.ToString()));
  base.Initialize();
 
  // Add our command handlers for menu (commands must exist in the .vsct file)
  OleMenuCommandService mcs = GetService(typeof(IMenuCommandService)) as OleMenuCommandService;
  if (null != mcs)
  {
    // Create the command for the menu item.
    CommandID menuCommandID = new CommandID(GuidList.guidFirstLookCmdSet, (int)PkgCmdIDList.cmdidShowMyMessage);
    MenuCommand menuItem = new MenuCommand(MenuItemCallback, menuCommandID);
    mcs.AddCommand(menuItem);
  }
}
 

First it calls the Initialize method of the base class — Package in this case. Omitting the call to the base implementation would prevent the package running correctly. Look at the call of GetService in Line 7! If you could select a method that is especially very important when creating Visual Studio Extensions, probably the GetService method is that one! This method is implemented by the Package class — many other Managed Package Framework objects also implement this method — in order to request service objects from the environment. GetService has one type parameter — it’s called service address — that retrieves a service object implementing the service interface specified by the address type.

So, Line 7 obtains an OleMenuCommandService instance that you can use to bind event handlers to so-called command objects. In Line 11 and 12 a CommandID instance is created to address the command to be put to the Tools menu. In Line 12 a MenuCommand instance is created to assigns the MenuItemCallback method as a response for the command specified with the CommandID instance. Line 13 entitles the menu command service to handle events related to the command. The result of this short initialization code is that your package handles the event when the user clicks the Simple Message menu item in the Tools menu by executing the MenuItemCallback method. In the next chapter you will find all nitty-gritty details about the command handling concepts used in Visual Studio and there you will learn much more about the initialization approach used here.

The MenuItemCallback method uses the IVsUIShell service to pop up a message box from within the IDE.

Registration Attributes

By now you know that packages are registered with Visual Studio in order to support the on-demand loading mechanism and allow merging menus and toolbars into the user interface of the IDE. The information to be registered is created during the build process from attributes assigned to the package class:

 [PackageRegistration(UseManagedResourcesOnly = true)]
[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
[ProvideMenuResource("Menus.ctmenu", 1)]
[Guid(GuidList.guidFirstLookPkgString)]
public sealed class FirstLookPackage : Package
{
  // --- Package body omitted
}
 

Packages are COM objects and so they must have a GUID uniquely identifying them. The Guid attribute is used by the .NET framework to assign this GUID value to a type. All attributes above except Guid are derived from the RegistrationAttribute class which is the abstract root class for all attributes taking a role in package registration. Table 3 describes the attributes decorating the FirstLookPackage:

Table 3: Registration attributes in FirstLookPackage

Source File	Description
PackageRegistration	Adding this attribute to a class, the build process will handle it as a package and looks for other attributes to prepare the package registration according to your intention. In the example this attribute sets the UseManagedResourcesOnly flag to tell that all resources used by the package are described in the managed package and not in a satellite DLL.
InstalledProductRegistration	This attribute is responsible to provide information to be displayed in the Help\|About dialog in the IDE. The constructor of this attribute requires four arguments with the following meanings: The first and second strings provide the name and the description of the package. The “#” characters indicate that these values should be looked up in the package resources with the IDs following “#”. The third “1.0” parameter is the product ID (version number). The fourth parameter (IconResourceID) tells which icon to use for the package. All resources (name, description and icon) should be defined in the VSPackage.resx file.
ProvideMenuResource	This attribute is to create registry entries about menu and toolbar items provided by the package. Visual Studio uses the embedded resources here to merge the package menus into the Visual Studio menus. The attribute has two parameters. The first is the so-called resourceID. This value is set to Menus.ctmenu as during the build process the VSCT compiler uses this value by default when adding the binary representation of the .vsct file to the package resources. The second parameter is called versionID and it plays important role in the caching mechanism of resources. In the next chapter you are going to examine the role of this attribute in details.

There are many other registration attribute beside the ones in the table above, later in the book we are going to meet a few of them. You are not constrained to apply only the registration attributes defined by the Managed Package Framework, and you can define your own attributes. Any of them including yours are handled on the same way by the build process as the predefined ones.

The Command Table

The wizard generated a file named FirstLook.vsct. It is an XML file and the file extension refers to the acronym coming from the “Visual Studio Command Table” expression. The schema of the XML file defines the command table owned by the package.

The command table is transformed into a binary format during the build process and is embedded into the package assembly as a resource. During the registration phase the ID of this resource is put into the registry. When Visual Studio starts, loads this binary resource information and merges it with the menus of the IDE including toolbars and context menus.

In order to avoid menu merges every time Visual Studio is launched, the IDE uses a cache mechanism and carries out the merge process only once for each package.

The next chapter will treat this mechanism and the structure of the command table in details. Listing 2 shows you the command table described in the FirstLook.vsct file.

Listing 2: FirstLook.vsct

 <?xml version="1.0" encoding="utf-8"?>
<CommandTable xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable" 
              xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <Extern href="stdidcmd.h"/>
  <Extern href="vsshlids.h"/>
  <Extern href="msobtnid.h"/>
 
  <Commands package="guidFirstLookPkg">
    <Groups>
      <Group guid="guidFirstLookCmdSet" id="MyMenuGroup" priority="0x0600">
        <Parent guid="guidSHLMainMenu" id="IDM_VS_MENU_TOOLS"/>
      </Group>
    </Groups>
 
    <Buttons>
      <Button guid="guidFirstLookCmdSet" id="cmdidShowMyMessage" priority="0x0100" type="Button">
        <Parent guid="guidFirstLookCmdSet" id="MyMenuGroup" />
        <Icon guid="guidImages" id="bmpPic1" />
        <Strings>
          <CommandName>cmdidShowMyMessage</CommandName>
          <ButtonText>Simple Message</ButtonText>
        </Strings>
      </Button>
    </Buttons>
   
    <Bitmaps>
      <Bitmap guid="guidImages" href="Resources\Images_32bit.bmp" usedList="bmpPic1, bmpPic2, bmpPicSearch, bmpPicX, bmpPicArrows"/>
    </Bitmaps>
  </Commands>
 
  <Symbols>
    <GuidSymbol name="guidFirstLookPkg" value="{d55758eb-6581-48fe-930b-f3536f43b6f0}" />
    <GuidSymbol name="guidFirstLookCmdSet" value="{05da2180-8d8e-4822-913b-b6a9012c4b2b}">
      <IDSymbol name="MyMenuGroup" value="0x1020" />
      <IDSymbol name="cmdidShowMyMessage" value="0x0100" />
    </GuidSymbol>
    <GuidSymbol name="guidImages" value="{49ba23b3-1631-483d-a095-003cb157f55d}" >
      <IDSymbol name="bmpPic1" value="1" />
      <IDSymbol name="bmpPic2" value="2" />
      <IDSymbol name="bmpPicSearch" value="3" />
      <IDSymbol name="bmpPicX" value="4" />
      <IDSymbol name="bmpPicArrows" value="5" />
    </GuidSymbol>
  </Symbols>
 
</CommandTable>
 

In this listing all comments placed into the generated file are omitted for saving space. However, it is worth to read those comments to have a better understanding of the command table structure.

The .vsct file tells a lot about how Visual Studio is architected, how it solves the coupling of functions (commands) and user interface elements.

Commands (actions to execute) are separated from the user interface element triggering the command. The same command can be assigned to different menus and toolbars; they will use the same action.
Commands used together can be grouped and simply merged into existing menus by using the command group representation. It is much easier then coupling commands with hosting menus one-by-one.
Elements are identified by symbols rather than using explicit values. This makes the coupling less error-prone: values of symbols must be defined only once, and the VSCT compiler can check for mistyping.

The root element of a .vsct file is the CommandTable element. As you can see all related elements are defined by the http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable namespace. No doubt, the most important element is Commands, because this node defines commands, their initial layout and behavior.

Any command in the VS IDE must belong to the IDE itself or to a package. To assign a command to the appropriate (owning) VSPackage, the package attribute of the Commands element must name the GUID of the corresponding package.

Commands node can have a few child elements; each has a very specific role.

Group elements define so-called command groups; each of them is a logical set of related commands that visually stand together. In the FirstLook.vsct file we have a Group element that holds only a Button. A button represents a piece of user interface element the user can interact with, in this case a menu item that can be clicked. The Parent element defines the relationship between elements, for example the Button element defined above is parented in the Group.

Toolbars and menus would be poor without icons helping the user to associate a small image with the function. The Bitmap nodes allow defining the visual elements (icons) used in menus.

The Symbols section is a central place in the command table file where you can define the identifiers to be used in the other parts of the .vsct file. You can use the GuidSymbol element to define the “logical container GUID” and the nested IDSymbol elements to provide (optional) identifiers within the logical container. The name and the value attribute of these elements do exactly what you expect: associate the symbol name with its value.

The VSPackage Wizard put the generated GUID values into the FirstLook.vsct file but they also can be found in the Guids.cs file. The PkgCmdID.cs file defines constant values for the IDSymbol values used by package commands. These three files must be kept consistent, so if you change a GUID or a command identifier, the changes should be tracked in the other files as well; otherwise your package will not work as expected.

Package Resource Files

The FirstLook project has two resource files: Resources.resx and VSPackage.resx. They both utilize the resource handling mechanism in the .NET Framework, but have different roles.

Resources.resx is to store functional resources that are consumed by the objects and services of your package. For instance, you can store error messages, prompt strings, UI elements, logos, and so on in this resource file and access them programmatically through the static members of the Resources class generated by the ResXFileCodeGenerator custom tool attached to the .resx file.

VSPackage.resx can store resources just like Resources.resx, but its primary role is to embed package infrastructure resources. This resource file does not use the ResXFileCodeGenerator custom tool and so does not generate any helper class to access resources.

As you remember the package is decorated with the InstalledProductRegistration attribute which refers to resource identifiers 110, 112 and 400:

 [InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
 

These IDs refer to string and icon resources in the VSPackage.resx file as shown in Figure 12.

Figure 12: String resources in VSPackage.resx

Package resources will be extracted from the content of the VSPackage.resx file, so if you put them in the Resources.resx file, the package will not find the resource. Although you can put functional resources into VSPackage.resx file, their recommended place is the Resources.resx file.

The Package Build Process

Understanding the package build process can help a lot when you are about to debug or deploy your application. In this part you’ll learn the steps of this process in details.

Building a package is not simply compiling the package source code into a .NET assembly. There are other important steps to complete in order to use the package either in the Experimental Instance or in its productive environment.

When the wizard generates the package it adds new build targets to the .csproj file of the corresponding class library. You can discover these entries by first unloading the project and then editing the project file. If you want to try it, first right-click on the project file in Solution Explorer and use the Unload Project function, then activate the Edit FirstLook.csproj command also with right-click. When you scroll down to the bottom of the file you can discover the following entries:

 <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\VSSDK\\uinput1?
  Microsoft.VsSDK.targets" />
 
 

The first Import entry can be found in any C# language projects to invoke the C# compiler and all the other tools (for example the resource compiler) to create the assemblies from the source project. The second Import entry is the one added by the VSPackage Wizard. The .targets file specified here contains Visual Studio SDK related build targets. If you would like to have a look at this file, you can find it in the MSBuild\Microsoft\VisualStudio\v10.0\VSSDK folder under Program Files. This book is not about MSBUILD, so you won’t find more explanations about what the build targets describe and how they internally work, instead, here are the steps of the package build process:

The Resources.resx and VSPackage.resx files are compiled into the corresponding .resource files.
With the help of the vsct.exe utility the content of the .vsct file belonging to the package is compiled into a binary file called CTO file. This file format is used by Visual Studio when merging the package menu and command information into the IDE menu.
The CTO file is merged into the VSPackage.resource file as a binary resource with the name of Menus.ctmenu.
The C# compiler is invoked to compile the project source code just like normally when we build a standard class library. During this step the Resources.resources file and the VSPackage.resources files are embedded into the assembly.
The CreatePkgDef.exe utility is executed and it scans the assembly for registration metadata information. Each registration attribute is translated to corresponding registry data. The utility is parameterized so that it creates a .pkgdef text file containing the information that is to be entered into the system registry.
The binaries of the package (including the .dll and .pdb file), the corresponding .pkgdef file and the VSIX manifest file are zipped into a file with .vsix extension. This .vsix file is the installation kit of the package. You will find this file just beside the binaries (in the bin\Debug or bin\Release or maybe in another folder depending on the build configuration). With double clicking on this file you can start the Visual Studio Extension Installer utility.
The .vsix file is installed in your LocalAppData folder under the Extensions subfolder of the Visual Studio Experimental Instance. The location of this folder depends on your user account and profile type. For example, if your user name is jsmith, you have installed Windows 7 on your C: drive and you have a local profile the build process will look for the C:\Users\jsmith\AppData\Local\Microsoft\VisualStudio folder and install the .vsix file under the 10.0Exp\Extensions subfolder. The extension will be enabled (setting a key in the registry).

As a result of the build process the package is available in the Experimental Instance. The next time you start the Experimental Instance, it scans the Extensions folder, uses the .pkgdef file of your package to create the appropriate registry settings, the package’s menus gets merged into the IDE, so your package is ready to run.

Debugging Visual Studio Packages

Anyone who develops software creates programming mistakes. Majority of them can be caught during a simple or more complex code review. Many of them are obvious and you can find them in the code after observing the faulty behavior. There are a few of them which cannot be easily caught without using a debugger.

Developing VSPackages is the same story. Sooner or later you find yourself debugging a package and searching for a bug. This book does not want to go into details about debugging techniques; this is definitely not its topic. However, you will learn how easy is to debug your package and what is going behind the scenes.

To debug or run a package you should set it as the startup project. If your package is the only project is the solution, it is already marked so. If you have more projects in the solution, you should mark any VSPackage project as the startup project.

Independently if you run a package with or without debugging, the Visual Studio Experimental Instance is started. You can check it on the project property pages on the Debug tab as Figure 13 shows it for the FirstLook project.

Figure 13: Debug properties

You can see that devenv.exe is selected as the startup project and it is launched with the /rootsuffix Exp command line parameters. As you have learnt before this command line starts the Experimental Instance.

When you start the project with the Start Debugging (F5) function Visual Studio attaches the debugger to the Experimental Instance and so you can set breakpoints in Visual Studio. As your package running in the Experimental Instance reaches a breakpoint, you are taken back to the debug view as Figure 14 illustrates it. In this case a breakpoint was set within the Initialize method of the FirstLookPackage class.

Figure 14: The debugger in action

You can use the same techniques for debugging a VSPackage as for any other applications. All debugging features of Visual Studio are accessible: you can watch variables, evaluate expressions, set up conditional breakpoints, and so on.

There are cases when you would like to trace your application without a debugger using trace messages. You can follow this practice with Visual Studio. The simplest one is writing to the Debug pane of the Output window. You can learn about this topic in Chapter 3.

Deploying a Package

It is very comfortable to use the Experimental Instance while developing a package. The build process takes care about setting up your package to work, so you can use either the Start Debugging or Start Without Debugging commands to try what you’ve created. However, when your package is ready for distribution you should care about deployment questions.

Package Deployment in the Past

With Visual Studio versions preceding 2010 developers had to do some extra activities to prepare packages for deployment and it has a few potential pitfalls. The two main issues were that you needed to obtain a so-called Package Load Key (PLK) through a web page and take care of entering the required entries into the registry to allow Visual Studio recognize and integrate your package.

¾ Any change in package information like name, GUID, company or version required obtaining a new PLK. The Experimental Hive (this is what is now called Experimental Instance) did not check the PLK by default, so it often happened that developers faced with a wrong (missing or not renewed) PLK only after the installation kit was built and tested in the production Visual Studio environment.

¾ While the build process automatically registered the package under the Experimental Hive, developers had to create their own registration mechanism in the installation kit. It was not difficult, but because it was not automatic, forgotten registration updates could have led to annoying issues.

The VSIX installation

The new deployment mechanism built into Visual Studio 2010 removes this pain and provides an easy and straightforward way for package deployment.

Generally the easiest form of deploying an artifact is if you have an installation kit. The package build process as treated earlier creates this installation kit as a .vsix file containing the package binaries and some additional information. You can distribute your package by simply distributing the .vsix file to your customers. When they receive it, the Visual Studio Extension Installer utility can be started with double clicking on the .vsix file as Figure 15 illustrates.

Figure 15: Installing a VSIX file

When you click install the content of the VSIX file will be installed to the specified Visual Studio instance.

If you create a package for a broad set of customers or for the community, you can upload the VSIX file to the Visual Studio Gallery. The new Shell of Visual Studio contains a great tool called Extension Manager that is able to search this gallery for extensions, install or remove them, and keep track of installed extensions as well as managing their updates. Figure 16 shows a screenshot of the Extension Manager browsing the extensions available on Visual Studio Gallery.

Figure 16: Browsing Visual Studio Gallery with the Extension Manager

You can select any of the components while browsing, and on the right pane of the window you find some more details about the highlighted item. With the More Information link you will be directed to component’s home page on the Visual Studio Gallery. If you like this component, you can get it with the Download button just as others can obtain your uploaded components. The Extension Manager is the recommended way to obtain extensions. Because it runs within a Visual Studio instance, you can use it to install a separate set of components for your development environment and for the Experimental Instance. When using the Visual Studio Extension Installer utility your components will be installed under the normal development environment by default.

It was mentioned earlier that the build process packages the binaries and some other files into the VSIX file. In order the installation process could understand your .vsix installation file you need to create a so-called VSIX manifest file that is the soul of the installation kit. This file describes the metadata that is used as the set of instructions about what, where and how should be put during the setup. The VSPackage Wizard automatically creates this manifest for you and names the file as source.extension.vsixmanifest. You are probably not surprised that the manifest is an XML file with its own schema. When the FirstLook package was generated the wizard created the manifest shown in Listing 3:

Listing 3: source.extension.vsixmanifest

 <?xml version="1.0" encoding="utf-8"?>
<Vsix Version="1.0.0" xmlns="http://schemas.microsoft.com/developer/vsx-schema/2010">
  <Identifier Id="d55758eb-6581-48fe-930b-f3536f43b6f0">
    <Name>FirstLook</Name>
    <Author>DeepDiver</Author>
    <Version>1.0</Version>
    <Description xml:space="preserve">Demonstrates the basic VSPackage concepts</Description>
    <Locale>1033</Locale>
    <InstalledByMsi>false</InstalledByMsi>
    <SupportedProducts>
      <VisualStudio Version="10.0">
        <Edition>Pro</Edition>
      </VisualStudio>
    </SupportedProducts>
    <SupportedFrameworkRuntimeEdition MinVersion="4.0" MaxVersion="4.0" />
  </Identifier>
  <References>
  </References>
  <Content>
    <VsPackage>|FirstLook;PkgdefProjectOutputGroup|</VsPackage>
  </Content>
</Vsix>
 
 

The root element of the manifest structure is the VSIX element that uses the http://schemas.microsoft.com/developer/vsx-schema/2010 namespace. The manifest contains three sections:

Identifier is used to uniquely define the different installation packages. The information here is used by the setup mechanism to manage the initial setup and the updates using the Id attribute and Version element values. This section also contains information describing the package and attributes taken into account during the setup process.
References element contains a collection of dependencies. Each item is a Reference element which defines a dependency on another product. In the FirstLook.vsix sample the package contains one dependency.
The Content element is a collection of content items that are packed in the payload. It our case the content is a VSPackage where the value of the item is used to generate the .pkgdef file containing the package information.

When running the Visual Studio Extension Installer or using the Extension Manager, the VSIX manifest is used to determine how the VSIX package should be set up. The VSPackage content type tells the installer that the related FirstLook.pkgdef file will contain the information to be put into the registry in order to register the COM object representing a Visual Studio package. The FirstLook.pkgdef file that has been created during the build process contains the information in Listing 4:

Listing 4: FirstLook.pkgdef

 [$RootKey$\InstalledProducts\FirstLookPackage]
@="#110"
"Package"="{d55758eb-6581-48fe-930b-f3536f43b6f0}"
"PID"="1.0"
"ProductDetails"="#112"
"LogoID"="#400"
[$RootKey$\Packages\{d55758eb-6581-48fe-930b-f3536f43b6f0}]
@="DeepDiver.FirstLook.FirstLookPackage, FirstLook, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8e5c6425e9b83cf4"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="DeepDiver.FirstLook.FirstLookPackage"
"CodeBase"="$PackageFolder$\FirstLook.dll"
[$RootKey$\Menus]
"{d55758eb-6581-48fe-930b-f3536f43b6f0}"=", Menus.ctmenu, 1"
 

The content of this file resembles to the content of a .reg file that can be exported from or imported to the Windows registry. However, the .pkgdef file contains a few tokens closed between dollar signs. The values of these tokens are passed by the context of the .pkgdef file to the entity processing the file content.

For example, if you use the Visual Studio Extension Installer utility to process the .vsix file, the utility extracts the payload into the Microsoft\VisualStudio\10.0\Extensions subfolder under the LocalAppData folder of your user profile. The files are put not directly into the Extension folder but into the subfolder calculated from the Author, Name and Version elements of the manifest’s Identity section. In this case the payload includes the FirstLook.pkgdef and FirstLook.dll files beside a few others.

When Visual Studio starts, it recognizes that a new .pkgdef file is under the Extensions folder and processes it. It substitutes the $RootKey$ token with the corresponding registry root of Visual Studio 2010, $Windir$ with the current Windows installation folder, $PackageFolder$ with the encapsulating folder of the .pkgdef file. After Visual Studio startup finishes, all information required to find and load the package is entered into the registry. When the first action demanding the package is executed, Visual Studio can pick up and initialize it.

Summary

A VSPackage is the principal architectural unit of Visual Studio, a container for extensibility objects. It is also a unit from deployment, security and licensing aspects. Packages are not loaded immediately as Visual Studio starts, they are read into the memory on-demand at the first time when any of their objects or services is about to be used.

The process of integrating a package physically into the Shell is called siting. While the package is not sited, its functions cannot be used from outside. As soon as the package gets sited, it is ready to finish its initialization and be fully functional. Siting happens when Visual Studio loads the package.

Visual Studio keeps track of packages installed through registration, and package information is stored in the system registry under a specific Visual Studio key. With command line parameters this registration key can be suffixed in order to use another configuration set — even with separate package registration parameters.

The Visual Studio SDK sets up the Visual Studio Experimental Instance which is a test bed to run and debug Visual Studio packages during the development and test phases. The Experimental Instance is not a separate Visual Studio installation, it uses the same devenv.exe file but with different configuration settings.

VSPackages use a build process that contains some additional steps in order to prepare the packages for debugging or deployment. The easiest way to create a package is running the VSPackage Wizard which sets up the build process appropriately. During this process package infrastructure resources — like to so-called command table — are embedded into the package assembly, the package installation kit is created and installed under the Experimental Instance.

During the development phase packages run inside the process space of the Experimental Instance and the same debug techniques can be used for tracing and troubleshooting as for any other .NET applications.

VSPackage deployment in Visual Studio 2010 became really simple related to the preceding versions. The package installation kit is represented by a VSIX file that can be distributed directly to the users of your package or — and this way opens up brand new opportunities — uploaded to the Visual Studio Gallery. The Extension Manager built into the IDE can be used to browse, install, and remove VSPackages (and many other kinds of extensions) as well as to keep track of them.

First Official SharePoint Experts Chat with a lot of MVPs

aghy — Tue, 02 Mar 2010 09:09:18 GMT

The very first Official SharePoint Experts Chat will coming on March 15, 9:00 a.m. Pacific Time (18:00 Central European Time): “Do you have tough technical questions regarding SharePoint for which you're seeking answers? Do you want to tap into the deep knowledge of the talented Microsoft Most Valuable Professionals? The SharePoint MVPs are the same people you see in the technical community as authors, speakers, user group leaders and answerers in the MSDN forums. This is the first time we have...(read more)

SharePoint Server 2010 Command Line Configuration

aghy — Thu, 25 Feb 2010 21:17:15 GMT

Lately, I’ve been installing a brand new SharePoint 2010 farm. The installation went smoothly, but the Configuration Wizard gave me a “Configuration Failed” message, with a TimeOut error in the 2nd step. Next try – the same result in the 5th step. After some trying I gave up to try again with the visual Configuration Wizard, but give a chance to the command line configuration. I made the following steps: 1. psconfig –cmd configdb – This steps is required if you run the configuration first. In my...(read more)

SPSEMEA Recordings Available for Download

aghy — Tue, 23 Feb 2010 10:57:14 GMT

Either you participated or not – SPSEMEA recorded sessions are available for download! Download them from here , extract and enjoy!...(read more)

New Expression Blend screencast series

vbandi — Thu, 11 Feb 2010 22:41:24 GMT

I have begun new series of screencasts on SilverlightShow.net. Here is the expert:

“As I promised earlier on Silverlight Show, this screencast series will show how to create the showcase application shown on www.response.hu (you may want to read the interview to get some background information on the project). The screencast series shows a real life example of how designers can add value to a project, and how a developer can support this effort by creating small, reusable behaviors that allow the designer to tweak things to shape the end result to be exactly as he wanted it.”

I would very much love to hear your opinion! Please leave feedback at the article, and let me know what you think about the format, the depth and the general direction it is going.

Extract styles in Expression Blend

vbandi — Tue, 19 Jan 2010 15:34:21 GMT

You may have found yourself in a situation when you want to convert an implicit style in XAML into a resource. Until today, I did it with creating the new style, and adding the setters manually. But I thought “There must be some way in Expression Blend to do this better”. I couldn’t find anything on the net, so I started to look for the solution myself. And yeah, I found it… Here is how it is done:

Suppose, you have a TextBox that has a lot of settings on it:

Now, you want to take the font settings, the drop shadow and the Black-Blue foreground gradient and reuse it on another TextBlock. Here is where extracting the style comes handy.

First, select the TextBlock, and choose Object / Style / Create Empty from the menu. There is NO right click option for this command! Then choose a name for your style resource.

Now, we are in Resource editing mode:

On the Properties tab, you can see all our settings.

But the Property Peg is empty (gray). What happens if we click on it?

Now, if we click on “Convert To Local Value”, the Peg turns white, and the Foreground gradient will be moved to the style!

You can see that the TextBlock does not contain the Foreground property anymore, but the TextBlockStyle1 style does. We can go and “Convert to Local Value” for all properties we want in the style. Even the drop shadow and the Perspective transform can be extracted this way.

Here is the end result:

Nice and clean XAML for the TextBlock, and the style is ready to be reused. Great!

SharePoint Saturday EMEA – This Saturday!

aghy — Tue, 19 Jan 2010 10:29:01 GMT

SharePoint Saturday EMEA is an all-day, online, free event aligned to the EMEA Time Zones, with speakers from around the world. It’s going to be a huge, awesome event, you should not miss out! You need more information , or want to register immediately? Don’t hesitate! See you on Saturday!...(read more)

Interview with Silverlightshow.net and a sneak preview of my next articles

vbandi — Sat, 16 Jan 2010 13:51:11 GMT

SilverlightShow recently published an interview with me. They asked about how the showcase app at www.response.hu came to be, and asked me to talk about two of my company’s award winning projects: The Muvesz WPF application (Architecture Journal article is here), and Zoomery, our Silverlight deep zoom framework.

In the interview, I also revealed that I will be doing a series of articles / screencasts on how the www.response.hu showcase app was built. The focus will be on using Blend with tips and tricks, and creating custom behaviors to give designers maximum control over the user experience. Essentially, we will go from this:

To this:

The first article should be up on SilverlightShow within a few weeks. I’ll keep you posted :)

Planning for Enterprise Search

aghy — Thu, 14 Jan 2010 15:21:05 GMT

Enterprise Search is one of the topics that required in every organization but sometimes it doesn’t get enough resources. I don’t mean CPU, memory, etc. but human resources during the plan, deploy and configure the search infrastructure and architecture. Let me summarize some key components that you need to plan if you’d like to deploy an Enterprise Search for your SharePoint. As Seach plays different roles in every different organization, there is necessary to plan deeply and deploy carefully for...(read more)

What Silverlight deed am I proud of in 2009?

vbandi — Mon, 11 Jan 2010 23:54:20 GMT

John Papa asked me (and other Silverlight MVPs) what was the one BIG thing we did around Silverlight in 2009. Here is what I had to say:

As a few of you may know, although I have technical background, I am really in love with Silverlight (and WPF) for the user experience it makes possible. I think my BIG thing was that I spread the love on tons of Silverlight and related topics during 2009. I had a 4 hour talk about UX, sketching and Sketchflow at the Architecture Forum; 4 hour talk about Silverlight, another one on NUI at the same place (and I got the highest ranks for the sketching talk out of 8 presenters). I talked about Silverlight 3 beta, and later about Silverlight 3 the next working day after it was released – in the middle of the summer, still over 90 people came. I participated in the local Silverlight 3 launch event later, in front of 500 people with sessions about SL3 and Blend. I had several other talks about Blend and Sketchflow, including a 5 minute(!) Sketchflow talk in front of Linux and Mac maniacs – and they liked it! I launched the Hungarian Silverlight User Group in December, and we already have 35 members, probably because they know me from the conferences. I wrote the WPF chapter of the book “Visual Studio 2010 and .Net Framework 4 Six-in-one” (http://www.amazon.com/Visual-Studio-2010-NET-Six/dp/0470499486), and convinced the editor to turn it around, focus on UX and Silverlight, and only add a little bit of WPF at the end. But the biggest result from all this preaching about UX and the great technologies that make it possible to concentrate on UX, is that I believe the Hungarian audience is starting to get it. They are realizing that getting developers to do UI may not be the best idea. They are realizing, that UX will be the differentiating factor for their products in the middle term. And spreading this word is my passion. Towards the last months of 2009, I started to receive feedback that the transition has started to happen in the minds of Hungarian developers and managers. This is probably what I am most proud of.

Another big thing for me (but maybe not for Silverlight :) ) is that I became part of this awesome group [Silverlight MVPs], and had the chance to meet many of you online, or even in person. 33 days from now, I will be sitting on a plane to meet even more fellow MVPs at the Summit. Can’t wait!

Happy New Year 2010!

aghy — Fri, 01 Jan 2010 20:11:47 GMT

I was pretty hidden in the last weeks: I wrote an article for SDN Magazine , and first time in my life: two chapters of a book! This book is not about SharePoint, but about Visual Studio 2010 and .NET 4.0 . A good friend of mine, Istvan Novak asked me to write these chapters about the history of .NET Framework and ASP.NET and I was very happy to work with him, moreover: all of the my Dotneteers friends are amongst the authors! Of course, we were also celebrating Christmas with my kids and family...(read more)

No more magic strings with VisualStateManager.GoToState

vbandi — Tue, 29 Dec 2009 22:00:00 GMT

This may come as no surprise for some, but only today have I discovered a way to get rid of the magic strings when changing states with the VisualStateManager.GoToState method. The way Microsoft and many others were explaining the Visual State Manager is via a sample code like this:

VisualStateManager.GoToState(control, "statename", true);

Unfortunately, this introduces a magic string, namely “statename”. The problem with the magic string here is that it creates a tight contract between the XAML (where the states are usually defined) and the code behind. It is very easy to mistype the name of the state in either place. Also, if the state is renamed by the designer in Blend, you get no compiler warnings or even runtime exceptions to point out the error.

Here is a small XAML sample using the Visual States to move an ellipse to the right of a Grid:

   1:      <Grid x:Name="LayoutRoot"  Background="LightBlue">

   2:          <VisualStateManager.VisualStateGroups>

   3:              <VisualStateGroup x:Name="SG1">

   4:                  <VisualStateGroup.Transitions>

   5:                      <VisualTransition GeneratedDuration="00:00:01">

   6:                          <VisualTransition.GeneratedEasingFunction>

   7:                              <ElasticEase EasingMode="EaseOut"/>

   8:                          </VisualTransition.GeneratedEasingFunction>

   9:                      </VisualTransition>

  10:                  </VisualStateGroup.Transitions>

  11:                  <VisualState x:Name="SG1Normal"/>

  12:                  <VisualState x:Name="SG1EllipseRight" >

  13:                      <Storyboard>

  14:                          <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Duration="00:00:00.0010000" Storyboard.TargetName="ellipse" Storyboard.TargetProperty="(UIElement.RenderTransform).(TransformGroup.Children)[3].(TranslateTransform.X)">

  15:                              <EasingDoubleKeyFrame KeyTime="00:00:00" Value="320"/>

  16:                          </DoubleAnimationUsingKeyFrames>

  17:                      </Storyboard>

  18:                  </VisualState>

  19:              </VisualStateGroup>

  20:          </VisualStateManager.VisualStateGroups>

  21:          <Ellipse x:Name="ellipse" Fill="Red" Stroke="Black"

  22:                   Height="116" HorizontalAlignment="Left" Margin="50,98,0,0"

  23:                   VerticalAlignment="Top" Width="235" RenderTransformOrigin="0.5,0.5" >

  24:              <Ellipse.RenderTransform>

  25:                  <TransformGroup>

  26:                      <ScaleTransform/>

  27:                      <SkewTransform/>

  28:                      <RotateTransform/>

  29:                      <TranslateTransform/>

  30:                  </TransformGroup>

  31:              </Ellipse.RenderTransform>

  32:          </Ellipse>

  33:      </Grid>

The key to my “discovery” is realizing that the VisualState elements have an x:Name attribute, and therefore fields get generated for them in the codebehind. So, instead of

VisualStateManager.GoToState(control, "SG1EllipseRight", true);

We can write:

 VisualStateManager.GoToState(this, SG1EllipseRight.Name, true);

Now, if the state gets renamed, at least we get a compiler error, and there is no way that you can mistype the state name.

Another advantage of accessing the states by name is that now it is easy to find when a state transition animation ends (like the one above). Just use the VisualState.Storyboard.Completed event:

SG1EllipseRight.Storyboard.Completed += (sender, args) => 
      MessageBox.Show("Ellipse move finished!");

That is two big problems that I had with Visual States solved. Now if only I could get the current state somehow…

Here is a little bonus:

You can also create some extension methods on VisualState as it may fit your way of thinking better:

    public static class VisualStateHelper
    {
        public static void Activate(this VisualState state, Control control, bool useTransitions)
        {
            VisualStateManager.GoToState(control, state.Name, useTransitions);
        }

        public static void Activate(this VisualState state, Control control)
        {
            state.Activate(control, true);
        }
    }

Now, to activate the SG1EllipseRight state above, all you have to write is:

SG1EllipseRight.Activate(this)

That’s all, folks!

Make a Silverlight TextBox update its binding on every character with a Behavior

vbandi — Thu, 24 Dec 2009 00:06:00 GMT

An old problem with Silverlight TextBox is that it only updates its binding when the TextBox loses focus. This can cause a lot of problems, especially for LOB applications. Following a short discussion on Twitter with Rob Eisenberg (@EisenbergEffect), I tried to create a proof-of-concept behavior that can help ease this pain, at least until Silverlight gets an UpdateSourceTrigger that can handle the PropertyChanged value. (You can read more about the problem Rob had on Connect).

The behavior itself is very simple:

   1:      public class TextBoxUpdateBehavior : Behavior<TextBox>

   2:      {

   3:          protected override void OnAttached()

   4:          {

   5:              base.OnAttached();

   6:              AssociatedObject.TextChanged += AssociatedObjectOnTextChanged;

   7:          }

8:

   9:          private void AssociatedObjectOnTextChanged(object sender, TextChangedEventArgs args)

  10:          {

  11:              var bindingExpr = AssociatedObject.GetBindingBLOCKED EXPRESSION;

  19:              AssociatedObject.TextChanged -= AssociatedObjectOnTextChanged;

  20:          }

  21:      }

The key is in the TextChanged event handler. We simply get the Binding expression for the Text property of the TextBox, and call UpdateSource on it.

I tested the behavior with both UI-2-UI binding and with binding to a ViewModel. Both work flawlessly, and they even work at the same time as this screenshot shows:

As you can see, the cursor is still in the TextBox, so I have not moved the focus away after typing.

Here is the entire XAML:

   1:  <UserControl

   2:      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   3:      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:      xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

   5:      mc:Ignorable="d" xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity" xmlns:local="clr-namespace:SLTextBoxUpdateBinder" x:Class="SLTextBoxUpdateBinder.MainPage"

   6:      d:DesignWidth="640" d:DesignHeight="480">

   7:      <UserControl.DataContext>

   8:          <local:TestVM />

   9:      </UserControl.DataContext>

  10:      <Grid x:Name="LayoutRoot">

11:

  12:          <StackPanel>

  13:              <StackPanel Orientation="Horizontal">

  14:                  <TextBlock Text="Binding using ViewModel: " Margin="10"/>

  15:                  <TextBlock Text="{Binding TestProperty}" Margin="10" />

  16:                  <Rectangle Fill="Black" Width="1" />

  17:                  <TextBlock Text="Binding using UI-2-UI binding" Margin="10" />

  18:                  <TextBlock Text="{Binding Text, ElementName=tb}" Margin="10" />

  19:              </StackPanel>

  20:              <StackPanel Orientation="Horizontal">

  21:                  <TextBlock Text="Enter text here to see it shown above. No need to tab away!" Margin="10" />

  22:                  <TextBox x:Name="tb" Text="{Binding TestProperty, Mode=TwoWay}" >

  23:                      <i:Interaction.Behaviors>

  24:                          <local:TextBoxUpdateBehavior/>

  25:                      </i:Interaction.Behaviors>

  26:                  </TextBox>

  27:              </StackPanel>

  28:          </StackPanel>

  29:      </Grid>

  30:  </UserControl>

I have attached the solution to this blog post. Marry Christmas everyone!

VS 2010 and .NET 4 Six-In-One: My last chapter submitted today…

inovak — Tue, 22 Dec 2009 13:08:53 GMT

A few weeks ago I shared the news with you that the Dotneteers team works on a book with an authoring team including other community members. Today I submitted my last (seventh) chapter dealing with the core enhancements of the .NET 4.0 Framework. The book is available on Amazon you can already preorder it. Visual Studio 2010 and .NET 4 Six-In-One will be published around Visual Studio 2010 launch time. Here is the short table of contents:

Chapter 1: History of Visual Studio and Current Editions
Chapter 2: VS UI Enhancements
Chapter 3: Visual Studio Snippets
Chapter 4: Visual Studio Templates
Chapter 5: Getting the most out of the IDE
Chapter 6: Extending Visual Studio
Chapter 7: .NET Framework Version History
Chapter 8: Window Presentation Foundation WPF
Chapter 9: Windows Communication Foundation
Chapter 10: Enhancements to the .NET Core Framework
Chapter 11: Enhancements to the .NET Workflow Framework
Chapter 12: Enhancements to the .NET Data Framework
Chapter 13: Enhancements to the .NET Communication Framework
Chapter 14: Enhancements to the .NET Client Framework
Chapter 15: .NET Charting Components
Chapter 16: ASP.NET Version History
Chapter 17: ASP.NET Charting Controls
Chapter 18: ASP.NET Dynamic Data
Chapter 19: ASP.NET MVC
Chapter 20: ASP.NET Ajax Improvements
Chapter 21: Ajax Control Toolkit, jQuery and More
Chapter 22: Visual Basic History
Chapter 23: Visual Basic 10 Language Improvements
Chapter 24: C# History
Chapter 25: C# 4 Language Improvements
Chapter 26: Other .NET Languages

However the book focuses on new features in VS 2010 and .NET 4, even those who use .NET 1.1 or VS 2005 right now may find it useful.

In the next few weeks you can read more details of the book, so stay tuned!

Another video from TechEd 2009

vbandi — Fri, 18 Dec 2009 16:17:18 GMT

Karen Young, the EMEA MVP lead has interviewed me last month in Berlin about who I am, what I did there and why I think being a developer is exciting. Here is the video:

Installing FAST Search Server for SharePoint 2010

aghy — Thu, 10 Dec 2009 12:04:10 GMT

No, this time I won’t write a full step-by-step install guide of FAST Search Server for SharePoint 2010. If you’d like to get a detailed install guide, please go to the Microsoft Download Center and download the B2FASTSearchDeploy.xps from there. This is a very detailed, 59 pages long guide. Ohhhhhhh, is it too long and would you like to get some shorter summary? – Yes, you can find some shorter summary around the blogosphere. BUT, please, be careful as generally they miss some very important steps...(read more)

SharePoint 2010 events

aghy — Tue, 01 Dec 2009 14:03:06 GMT

Last week a lot of us were headed to Slovenia, to the Slovenian SharePoint Conference 2009 . It was an awesome conference, with a lot of useful and interesting SharePoint 2010 sessions. It’s a honor to me that I was one of the speakers as well the SharePoint Days as the Conference itself. My slide decks will be available to download from the conference site soon. Here are some upcoming events, either you missed the Slovenian SharePoint Conference or attended it but you’re interested in more SharePoint...(read more)

SharePoint Server 2010 Prerequirities

aghy — Thu, 19 Nov 2009 22:30:59 GMT

In case of you have to install SharePoint 2010 to a machine with no Internet access, here are some useful URLs where you can download these required components (and copy them manually to your offline machine): Geneva Framework, Microsoft.IdentityModel.dll 1.0.0.0: http://download.microsoft.com/download/F/3/D/F3D66A7E-C974-4A60-B7A5-382A61EB7BC6/MicrosoftGenevaFramework.amd64.msi (Be careful, Geneva Framework Beta2 comes with the DLL version 0.6.1.0 instead of 1.0.0.0) Microsoft Chart Controls for...(read more)

Discovering Silverlight 4 – What is new?

vbandi — Wed, 18 Nov 2009 21:24:00 GMT

Today, at the PDC in Los Angeles, Scott Guthrie revealed Silverlight 4 in his keynote. The painful silence enforced by the NDA is now over, and I can talk about all the cool new stuff on Silverlight 4!

To me, the most amazing thing is how much the Silverlight team has been listening to the community. Just take a look at the Top 10 most requested SL4 features at: http://silverlight.uservoice.com/pages/4325-feature-suggestions, and compare it with the whatsnew document - 8 out of the top 10 requests are in the Beta, except for the two where iPhone and other device support is discussed. This is an amazing proof that the Silverlight Team is really customer-driven, congrats!

So, here is the official “Summary of Features New in Silverlight 4”, with some of my additional explanations:

Runtime: Silverlight 4 is based on the CLR4 runtime. This means that we can use all the cool dynamic stuff from C# 4.0 – much easier to communicate with DOM objects, Javascript, etc.

Out of Browser Apps
- Elevated Privilages Support – this is really huge, removes most of the security restrictions. A great new way to write more full-featured cross platform applications!
  - Cross Domain Networking Access – no more proxies for you Twitter client…
  - Full file path from Open/SaveFileDialog
  - No User-Initiation Requirement for Full Screen, Open/SaveFileDialogs – however, you can only access files directly within the My Documents folder or the Mac equivalent
  - COM Interop: obviously, this is Windows only. C# 4.0 dynamics helps here a lot…
- HTML Hosting Support – it would really be useful within the browser as well, but there were too many security considerations to make it happen in this release. Still, I can’t wait to see what people will cook up with this one
Media
- WMS Multicast Support – Save your server’s bandwidth when streaming videos!
- MP4 Playback Protected by PlayReady DRM – Should help ease Hollywood’s mind a little bit…
- Offline DRM – Download songs and movies, and play them without a network connection on the plane
- Output Protection – again, for helping Hollywood accept online media…
- WebCam / Mic Support – This is raw access only to the webcam or microphone data – nothing fancy like streaming it to a server, etc. I am sure, the community will come up with that pretty soon…
Printing – The number one requested feature, that was the biggest setback when discussing Silverlight based Line Of Business applications.
Text
- RichTextBox
- Arabic and Hebrew Text Support – I had a few people specificly asking for this while helping out at the “Ask The Experts” booth during the TechEd in Berlin. I wish I could tell them what I knew… NDA sometimes sucks
- IME Improvements for TextBox
- UIElement.TextInput event – for when you want to validate or update on text changes in your textbox
Controls, ControlModel, Layout
- Theming via Implicit Styles – No more need to specify styles for each and every button in your app
- ViewBox – This extremely useful layout control is now mover to the the core runtime from the Toolkit
- MouseWheel Support on ScrollViewer, TextBox, Combobox, Calendar, DatePicker – Yeah! I’ve missed it a lot
- RTL Layout via UIElement.FlowDirection property – this one will also make some countries’ developers happy
- VisualStateGroup.CurrentStateGroup property – no more need to follow / guess states yourself. Altough a well-behaving ViewModel should already know the Visual State of the View…
- CommandProperty on ButtonBase & hHyperlink – Commanding is slowly getting there
- SelectedValue and SelectedValuePath properties on Selector – very convenient thing for simple dropdowns, etc.
- Drop files onto Silverlight from Exporer or Finder (Mac) – no need to browse, just drop files onto Silverlight!
Networking
- Memory Usage Fix During Progressive Downloads – it is always good to fix memory usage
- Automatically adding Referrer Header – behaving like a good citizen
- Authentication Support on ClientHttpWebRequest – this one was really missed
Tools Support
- Dispatcher Support on the Tools Design Surface
Databinding improvements
- DataBinding Support for DependencyObjects – Yeeeey! Now you can bind to behaviors, and so much more. This one opens up quite a few new possibilities
- IDataErrorInfo Support
- StringFormat, TargetNullValue & FallBackValue properties on Binding – This can save a lot of error handling code and replace basic converters
- ObservableCollection<T> constructor that takes INumerable or IList – Quickly fill up your ObservableCollection with data.
- IEditableCollectionView
- Grouping support on CollectionViewSource
SDK
- Astoria 2.0 Support
- MEF – I am really interested in how this one works. As Yoda would say: “A lot of extensible Silverlight Applications in the future I see”.

This is a pretty impressive feature set, especially as it has only been 4 months since the release of Silverlight 3. What do you think?

Why these days are so important for us?

aghy — Wed, 18 Nov 2009 08:50:18 GMT

2010 is here! Don’t panic, not in the calendar yet, we’re in the middle of November, 2009 right now. But if you’re an MSDN subscriber, most probably you’ve found the surprises on your download site: Yes, SharePoint Foundation 2010, SharePoint Server 2010 and Office 2010 Beta2 applications are available to download. To be honest, I’ve been using the Technical Preview for months, and I’m absolutely love them. I’m sure you also will…...(read more)

My Teched Online talk: “Why Take User Experience Seriously?” is online

vbandi — Wed, 18 Nov 2009 06:52:38 GMT

During TechEd Europe, my friend István Novák interviewed me about user experience. Here is the resulting video:

Why Take User Experience Seriously?

The software development industry is changing; the focus is being shifted from technology to the users. Silverlight MVP András Velvárt shares his thoughts on why UX focus is a must for development teams, and what you can do to incorporate UX into the development process.

In return, I also interviewed István, and he talked about Deploying Visual Studio 2010 Extensions:

Due to the COM roots of Visual Studio and the lack of the right tool set, deploying Visual Studio extension requires "creativity" from developers. Visual Studio 2010 is a great leap on this field with its brand new tools and technologies, including Extension Manager, Visual Studio Gallery and VSIX. This discussion will provide an overview of these tools and demonstrate how developers can leverage the synergy of these tools to remove the deployment pain.

PDC 2009 Keynote – Tuesday

inovak — Tue, 17 Nov 2009 15:52:08 GMT

After 2008 Microsoft organized a PDC again without waiting for two or more years, as it usually happened in the past. Right now I’m setting here in the main auditorium of Los Angeles Convention Center and watching this years keynote. Well, people around my typing on their notebooks, writing their blogs or twitting about what they see and hear.

Yesterday the first new thing happened, even before any official announcement, Microsoft Office 2010 Beta went to the MSDN Download Center. I’ve already started downloading it…

A short summary about what kind of messages I’ve got during this keynote:

Ray Ozzie, Chief Software Architect

Windows Azure: One coherent model using Windows Server and System Center. Tools for developers: Windows Azure tools for Java and Eclipse, PHP application support

Guest: Matt Mullenweg, Automaitc, manufacturer of WordPress:

Now WordPress works on Azure (oddlyspecific.com as one example)

Guest: Loic LeMear, Seesmic

Created Silverlight prototype for a new Twitter browser. Easy to use with user lists, custom-defined columns. They are going to create a platform around this app allowing plug-in development.

Ray Ozzie, Chief Software Architect

Announcement: Microsoft PinPoint for finding online Sharepoint and Exchange applications and other solutions
Announcment: Microsoft Codename “Dallas” CTP, creating a uniform access and discovery for data, Data-as-a-Service

Don Box, Chriss Sells:

C++ code runs on Windows Azure, they demonstrated it.
SQL Azure is easy, SQL Management Studio 2008 R2 supports it.

Bob Muglia, President, Server and Tools Business

Announcement: Your enterprise services connected to Windows Azure, code name “Project Sydney”
Announcement: Windows Azure Virtual Machine Role
Announcement: Windows Azure AppFabric (Caching, Workflow Hosting, Monitoring)
Announcement: Windows Identity Foundation RTM

Cameron Skinner:

Demos Azure development support with VS 2010 (AppFabric, WIF)

If you can, watch the PDC Keynote video you can access from here.

Getting Started – How to Create an External List from Scratch?

aghy — Wed, 11 Nov 2009 23:26:25 GMT

As the next part of my Getting Started series, let’s see how we can create external lists - without any coding! Probably you’ve already heard the expressions “external list”, “external content type”, “Business Connectivity Services (BCS)”, etc., but do you really know what they mean? If your answer is yes, fell free to step over the next paragraphs :) Business Connectivity Services (BCS) provides the capability to connect SharePoint 2010 and Office 2010 client applications to external data sources...(read more)