How to build a package for VS Shell

I said I would follow up with a post on how to build a VS Package that targets the VS Shell, so here it is.

Creating a VSPackage for the isolated Shell is a little different than the other two scenarios because you will also need to create your own stub .exe, and VSPackages need to be registered differently. Note that these are the only real differences; there is both source- and binary- level compatibility for VSPackages across Visual Studio and the Shell editions.

When you deploy a VSPackage that targets an isolated Shell, you create package definition files (.pkgdef) that contain the registry information that you would normally apply directly to the registry if you were targeting Visual Studio or the integrated Shell. If you are using the managed package framework for your extension, you can easily produce such package definition files by using the /pkgdeffile switch with the regpkg.exe tool that ships with the Visual Studio SDK. Remember also to use the /codebase switch unless you are planning on GAC'ing your assembly (you wouldn't do this usually). Once you have produced the .pkgdef files, you just need to place them into a special PackagesToLoad folder along with your package binary, and your instance of the isolated Shell will automatically detect and install this new package when it is run with the /setup switch. Usually, you will run <yourAppName> /setup as a custom action in your setup program.

When you are building on the isolated Shell, you will also need to create your own stub .exe file. This is logically equivalent to devenv.exe for Visual Studio, and it is automatically generated for you when you are choosing to create a Shell instance with the Visual Studio SDK. As part of your setup program, you will also need to install this .exe, in addition to your VSPackage and the redistributable package.

 

That's it for now. While I know there are still bugs with VS Shell, I hope this will get you started. Let me know how things go!

thanks,
James

Comments

• Anonymous
  August 04, 2007
  I said I would follow up with a post on how to build a VS Package that targets the VS Shell, so here

• Anonymous
  August 08, 2007
  Could you elaborate some more on this? For instance, in the PackagesToLoad folder that is automatically generated by the Shell project, there is a 1033 folder with the stub UI binary, while the stub UI pkgdef file is placed directly in the PackagesToLoad folder - so do we follow this pattern or what you said and place everything directly in the PackagesToLoad folder? Also the project does not by default include a /setup switch when running the stub exe. Currently adding this switch in manually causes a bunch of assemblies to be loaded, about a 1 minute wait, and then an error occurs (in free.c). Also doing a manual clean is necessary for some actions to take effect, ie, changing the splash screen image won't work if you previously built the solution unless you erase all the "Debug" folders first.  So can you please post a full, detailed step by step description of getting the shell with a basic vspackage (a menu perhaps) to work correctly? At the moment it seems like getting the shell to run with a VsPackage is simply broken.

• Anonymous
  August 08, 2007
  Hey Jason, Thanks for your feedback. I will try to find time to document this on the blog at some point. But right now, you can try the following.

1. When you use regpkg.exe to generate your .pkgdef file, remember to use the /codebase switch along with the /pkgdeffile.
2. Place the .pkgdef file and the package binary in the PackagesToLoad folder.
3. Instead of hitting F5 in VS and have VS detect and run /setup on your app, the simplest thing to do right now is to go outside of VS and use an admin-elevated command prompt to run <YourApp>.exe /setup. This will force your app to re-inspect the contents in PackagesToLoad and re-register any packages. Now you should be able to just run your app and have your package show up. I hope that helps. I know you have to jump through a lot of hoops right now to get your package to work. Remember, this is still a preview release, and we will continue to improve on the development experience with future releases of the VS SDK. thansk, James