Cannot run VSPackage when developing on multiple machines

Question

We are working on a VSPackage in a team, using Visual Studio 2012 and TFS.

The extension works fine on the computer used to create it (through a wizard). On another computer, Visual Studio says that "a project with output type of class library cannot be started directly" when we attempt to run it (with F5).

The output of the project is indeed class library, and pressing F5 on the first machine starts Experimental Instance of Visual Studio with the extension loaded and working.

By looking at %LOCALAPPDATA%\Microsoft\VisualStudio\11.0Exp\Extensions on the second computer, we see that the extension had been built and there was an attempt of registering it with VS. We have also created another extension on the second computer and tried to run it on the first machine. It displays the same error.

How can we get the extension to run on computers which were not used to create it?

Unicycle

I have this problem on the same machine: The main source code is on path C:\Dev-1` I checked out the same source code to the path C:\Dev-2` now the new copy gives me the same error you get. – Transudation

Try launching Visual Studio with rootSuffix exp2 or something else - this way, the new copy will go to a brand new experimental instance of VS, and won't conflict with the extension from C:\Dev-1 – Unicycle

@Matze's answer solved the issue. Thanks. – Transudation

Answer 1

The Visual Studio package project type adds an additional tab to the project properties view named VISX. On that tab the Deploy VSIX content to experimental instance for debugging option is checked by default; that´s the reason why package files are copied to the extensions directory of the current user´s profile after build.

If you want to start Visual Studio using the experimental hive you must customize the Debug settings of the class library project. Set the Start Action to Start external program and select the devenv.exe file (the file´s location depends on your installation folder) and specify the following commandline arguments:

/rootSuffix Exp

This allows to debug the extension by pressing F5.

Cellular

Thank you! To further discuss the problem, this particular information is stored in Projectname.csproj.user file, which doesn't seem to be shared over TFS - it's neither in included changes nor in excluded changes. This will be a manual fixthat needs to be done done on each machine. – Unicycle

You´re right; by default the .user files are ignored from the list of pending changes (for good reasons). – Cellular

Yes, same problem once I put the local code to source control. .user file was not checked in and got me into trouble. – Jacobba

Finally! I'm finally back in business thanks to you, thanks so much. BTW, I needed to complete the steps in this other answer as well in order to get it to work: #7767749 – Mendiola

Putting it in a .props file placed under version control should work the same without requiring a custom .user file. – Harwin