After a debugging session last night and some problems with the Visual Studio 2012 environment and settings concerning Visual Studio Extensibility (VSX), I want to write down some configuration hints. In the first place these hints are mainly for myself. Because I know I forget them so fast, I just write them down here :). But maybe they are helpful for someone else, too.

Visual Studio won’t start the Package

This is a very common problem. After a fresh checkout from some version control system, in this case Git, the Visual Studio solution hast lost some settings. I don’t know when this happens mainly, but I ran into this problem many times. The complete error message is shown in figure 1.

Fig. 1: VSX Class Library Start Error.

And of course, on the other system were I set up the project one day before, Visual Studio 2012 can start the project without any problems. In detail the message is correct. Of course, a Visual Studio project that implements a package, is nothing more than a class library project with the Visual Studio Extensibility magic. It will be installed in the Visual Studio host as a library and must therefore not be executable directly. But the problem can be handled very easily. Just change the project configuration as shown in figure 2. Thereby Visual Studio will not try to run the project directly like a console application, but rather it will start the given program. In this case another Visual Studio instance.

Fig. 2: VSX Package Configuration.

Additionally the string /rootsuffix Exp must be placed in the field Command line arguments. Without this particular configuration no extensibility project under development will be loaded within this instance. No Visual Studio Package nor Add-Ins. But that’s the main reason for starting this instance.

After both configurations are made, the Visual Studio 2012 behavior is the same as when a clean and new Visual Studio Extensibility project was set up.

Clean up loaded packages

I’ve played around much with the Visual Studio Extensibility in the last days. I’ve created many VSX projects to test a particular idea. Because I’ve created a menu command and a tool window in every single project, Visual Studio must load many additional packages. But that’s not the main problem. Some menu commands have the same name. It is very annoying to determine the correct menu item to execute the correct command. Especially when the code behind these wrong commands won’t work properly and Visual Studio can crash or show many error messages.

In that case it is a good idea to delete some or eventually all developed extensibility projects from the experimental Visual Studio 2012 instance. Just go to the directory

C:\Users\<User>\AppData\Local\Microsoft\VisualStudio\11.0Exp\Extensions

and delete the packages you want to remove. The whole extensions directory can be deleted, too. It is recreated automatically when the Visual Studio experimental instance starts the next time.

Conclusion

Maybe this really short tips are helpful for someone else. As I mentioned in the introduction, these tips are mainly for myself, because I will search for them in the next VSX project for sure.