Introduction to the Visual Studio 2008 Shell (Cont.) Removing a Default Package from Your IDE When you develop your own VS Shell-based IDE, you also have the ability to remove default registrations for any packages that you do not want to include in your IDE. This is done via the .pkgundef file. Your Shell project contains a file called MyFirstShell.pkgundef and it is located in the same folder as MyFirstShell.pkgdef. You can use the .pkgundef file to unregister any packages that you don’t want to be registered for your IDE. The format you use in this file is the same as the MyFirstShell.pkgdef, but the effect of putting a registry key in it is that it will be removed. For example, you can unregister the Web application project package by specifying the line in your .pkgundef file (Figure 10).  Figure 10: MyFirstShell.pkgudef entry to remove the Web application project package registration.You will need to clean and rebuild your solution for this to take effect. Adding a Package to Your IDE Next, I will show you how you can add a VSPackage to your customized IDE. Creating a VSPackage for the isolated Shell is a little different than general VSPackage development because the VSPackage needs to be registered differently. Note that is the only difference; there is both source- and binary-level compatibility for VSPackages across Visual Studio and the Shell editions. You can start by right-clicking on your solution and choose Add > New Project… In the New Project dialog box, choose Visual Studio Integration Package under the Other Project Types > Extensibility node. Rename your package to ShellPackage and click OK. You can quickly run through the wizard to create your package. Make sure your inputs match Figures 11-16.  Figure 11: Page 1 of Visual Studio Integration Package Wizard. Figure 12: Page 2 of Visual Studio Integration Package Wizard. Figure 13: Page 3 of Visual Studio Integration Package Wizard. Figure 14: Page 4 of Visual Studio Integration Package Wizard. Figure 15: Page 5 of Visual Studio Integration Package Wizard. Figure 16: Final page of Visual Studio Integration Package Wizard.On the last page, click Finish. Now your solution should have the new package project added. You can immediately build this package by right-clicking on the project and choosing Build. The output is a perfectly valid package assembly that you can run inside Visual Studio. However, since you are now trying to load this package inside your IDE, you will need to take some additional steps. A VSPackage that runs in a VS Shell-based IDE needs to have an associated .pkgdef file. This file essentially contains the registry information to properly register the package. The best way to create this file is to use the regpkg.exe tool that ships with the SDK. To support package development for the VS Shell, Microsoft added a new /pkgdeffile switch to this tool. You can use the regpkg.exe tool with this switch to generate the required .pkgdef file. Open a command prompt and change to your VS SDK’s tools directory. On my machine, this is C:\Program Files\Microsoft Visual Studio 2008 SDK\ VisualStudioIntegration\Tools\Bin\. Then run the following (all on one line): Regpkg.exe /pkgdeffile:<ShellPackageAssemblyDir>\ ShellPackage.pkgdef /codebase <ShellPackageAssemblyPath>
Figure 17 shows the command running successfully on my machine.  Figure 17: Running regpkg.exe with/pkgdeffile and /codebase to generate .pkgdef file.Now, you need to copy both the assembly and the associated .pkgdef file into a special folder called PackagesToLoad in your IDE project. You should find the PackagesToLoad folder located in My Documents \Visual Studio 2008 \ Projects \ MyFirstShell \ Debug \ PackagesToLoad. Once you have copied the two files over, you can run MyFirstShell /setup in an administrator-elevated Command Prompt to register the package. You can start an administrator-elevated Command Prompt by right-clicking on the Command Prompt shortcut and choosing Run as administrator(Figure 18).  Figure 18: Run Command Prompt as administrator.The command will return immediately from the command prompt, but your process is still running to perform the setup. You can use Task Manager to make sure MyFirstShell.exe is finished running before moving on. Once it has completed running, you can run it again without the /setup switch to launch the IDE. You will now see your command from your newly added VSPackage added under the Tools menu (Figure 19).  Figure 19: My First Shell with new command added crom a VSPackage.You will also find the command to start your newly added Tool Window under View > Other Windows(Figure 20).  Figure 20:My First Shell with a new Tool Window command added from a VSPackage.Deploying Your IDE To deploy your IDE, you will need to create your own Setup program that chains the VS 2008 Shell (isolated mode) Redistributable Package. The redistributable package contains all binaries of Visual Studio that makes up the Shell, as well as the .NET Framework 3.5, which is a pre-requisite. The redistributable is shipped as a single self-extracting EXE that you can use with a number of deployment technologies such as InstallShield to include in your Setup program. At the time that I’m writing this article, Microsoft has not yet made the redistributable package available yet, but it will be available later in the year. In order to deploy your VS Shell-based IDE on to the end user’s machine, you will need to obtain both a shell load key (SLK) and package load keys (PLKs) from the VSIP Members site (http://www.vsipmembers.com). The IDE and packages will not load if these load keys are not included. Your VS Shell-based IDE works on your machine because the VS SDK installs a developer load key (DLK) that causes the load key check to be bypassed. Since your end user will not have the DLK installed, you will need to obtain the SLK and PLKs to make an actual deployment work. Microsoft is redesigning the site and the process for obtaining load keys as I’m writing this article, so I won’t go through the experience in detail. For now, you just need to be aware that you need to get these load keys when you are ready to deploy. You can view our Extensibility Developer Center (http://msdn.com/vsx) or search on MSDN for more information about obtaining SLKs and PLKs. Final Comments I hope this article has given you a good overview of the Visual Studio 2008 Shell. VS Shell development can often be complicated. The VSX team realizes this and we plan to make the development experience more seamless over the next several VS SDK releases. For example, we expect to allow developers to explicitly create VSPackages that target their own VS Shell-based IDE so that they don’t need to manually generate .pkgdef files. I strongly encourage you to visit our Extensibility Center (http://msdn.com/vsx) frequently to get important updates about the Visual Studio Shell. You should also bookmark the VSX team blog at http://blogs.msdn.com/vsxteam for the latest. I have only scratched the surface with this article and you can expect more in-depth technical articles in the near future from us. James Lau is the Lead Program Manager in the Visual Studio Ecosystem team at Microsoft. His team produces the Visual Studio SDK, and helps third-parties build great extensions for Visual Studio. Before joining the Ecosystem team, James was part of the Visual Studio IDE team where he designed and drove a number of IDE features. You can read his blog at http://blogs.msdn.com/jameslau/. James Lau |