Fortunately, the fix is simple. Go to the Windows Programs and Features control panel and uninstall the Visual Studio 11 Beta.

http://visualstudio.uservoice.com

In this post, I’ll walk through the process of getting a C#/VB VSPackage project up and running on Team Foundation Build, without requiring an install of Visual Studio on the build agent machine. The same steps apply for editor extensions or other extensibility project types.

Once you’ve configured the build server and are ready to try out a build, you’ll probably see something like the following error in your build log:

Step #1: Put Visual Studio SDK targets/tasks in source control

Since neither Visual Studio nor the Visual Studio SDK are installed on my build machine, the build complains about the missing Microsoft.VsSDK.targets file. This is simple enough to fix by doing the following:

1. Create a folder at the root of your solution directory called “vssdk_tools”. We’ll be adding all the necessary targets, tasks, etc… to this folder and adding it to source control.
2. Copy the contents of %ProgramFiles%\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK into this directory.
3. Add the contents of your vssdk_tools directory to source control.
   • If you’re using TFS Source Control, you can do this via the “tf add” command or through the Source Control Explorer tool window in Visual Studio 2010.
4. Edit your project file to point to this new targets file. Change the line:
   <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets" />
      to
   <Import Project="..\vssdk_tools\Microsoft.VsSDK.targets" />

Let’s try checking in again and seeing where we are now:

Step #2: Put COMReference binaries in source control

The reason that MSBuild is trying to run AxImp.exe is because we have a collection of COMReference elements in our VSPackage project. Instead of registering these assemblies as COM components on the build server, let’s copy these binaries to our local project and add them as normal assembly references:

1. Remove the following COMReferences from your project:
   • EnvDTE
   • EnvDTE80
   • EnvDTE90
   • EnvDTE100
   • Microsoft.VisualStudio.CommandBars
   • stdole
2. Create a “binaries” folder in our VSPackage project
3. “Add existing item…” on this binaries folder for the following assemblies:
   • %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE.dll
   • %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE80.dll
   • %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE90.dll
   • %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE100.dll
   • %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\Microsoft.VisualStudio.CommandBars.dll
   • %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\stdole.dll
4. Select all the binary files and set the “Build Action” property to “None”.
5. Re-add assembly references to the binaries you just added.
6. Important: Select all the references and set the “Embed Interop Types” property to false. (You can select and change them all in one operation.)

Let’s check in and try another build on the server

Step #3: Manually set the VsSDKInstall locations

Let’s take a look at the actual line where we’re hitting the error in Microsoft.VsSDK.Common.targets:

<Target Name="FindSDKInstallation" Condition="'$(VsSDKInstall)'==''">
  <FindVsSDKInstallation SDKVersion="$(VsSDKVersion)">
    …

The reason this task needs to run is because the VsSDKInstall property (and friends) hasn’t been set yet. Let’s use the “vssdk_tools” folder we had set up earlier. Edit your project file again, and add the following properties to the first <PropertyGroup> element:
 

<VsSDKInstall>..\vssdk_tools</VsSDKInstall>
<VsSDKIncludes>$(VsSDKInstall)\inc</VsSDKIncludes>
<VsSDKToolsPath>$(VsSDKInstall)\bin</VsSDKToolsPath>

Clearly, this won’t work until we actually have the corresponding files from the Visual Studio SDK also checked in to those directories. Let’s do that now:

1. Copy the contents of %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Inc to vssdk_tools\inc
2. Copy the contents of %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Tools\Bin to vssdk_tools\bin
3. Add all these new files to source control

Let’s checkin again and see where we are now:

Step #4: Set VsSDKToolsPath as an Environment Variable

Hmmm…this one is a bit tricky. It turns out that some of the VSSDK build tasks rely on not only the $(VsSDKToolsPath) MSBuild property, but they also rely on this being set as an environment variable. We can do that fairly easily with an inline build task which we can add to our project file:

<UsingTask TaskName="SetVsSDKEnvironmentVariables" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll">
  <ParameterGroup>
    <ProjectDirectory Required="true" />
  </ParameterGroup>
  <Task>
    <Code Type="Fragment" Language="cs">
      System.Environment.SetEnvironmentVariable("VsSDKToolsPath", System.IO.Path.GetFullPath(ProjectDirectory + @"\..\vssdk_tools\bin"));
    </Code>
  </Task>
</UsingTask>
<Target Name="SetVsSDKEnvironmentVariables" BeforeTargets="VSCTCompile">
  <SetVsSDKEnvironmentVariables ProjectDirectory="$(MSBuildProjectDirectory)" />
</Target>

Let’s cross our fingers and try again:

Step #5: Use 32-bit MSBuild.exe

By default, TFS will use the x64 version of MSBuild.exe (assuming you’re on a 64-bit server). Since the VSCT assembly is 32-bit only, it will fail to load in a 64-bit process. To use 32-bit MSBuild.exe on the server (if you’re using Team Foundation Build), simply edit the build definition and change Process => Advanced => MSBuild Platform to “X86” instead of “Auto”.

One more try:

Step #6: Add other VSSDK Assemblies to source control

In step 3, we only added the COMReferences to source control. Now, let’s do a similar procedure with the other assemblies:

1. Remove the following assembly references from your project:
   • Microsoft.VisualStudio.OLE.Interop
   • Microsoft.VisualStudio.Shell.10.0
   • Microsoft.VisualStudio.Shell.Immutable.10.0
   • Microsoft.VisualStudio.Shell.Interop
   • Microsoft.VisualStudio.Shell.Interop.10.0
   • Microsoft.VisualStudio.Shell.Interop.8.0
   • Microsoft.VisualStudio.Shell.Interop.9.0
   • Microsoft.VisualStudio.TextManager.Interop
2. “Add existing item…” on the binaries folder for the following assemblies:
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.OLE.Interop.dll
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.dll
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.8.0.dll
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.9.0.dll
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.10.0.dll
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.TextManager.Interop.dll
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v4.0\Microsoft.VisualStudio.Shell.10.0.dll
   • %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v4.0\Microsoft.VisualStudio.Shell.Immutable.10.0.dll
3. Select all the binary files and set the “Build Action” property to “None”.
4. Re-add assembly references to the binaries you just added.

One more time…

Step #7: Add Microsoft.VisualStudio.Shell.Immutable.10.0.dll to the tools directory

CreatePkgDef.exe is the tool used to create a pkgdef file for your VSPackage. The tool itself relies on types defined in the Microsoft.VisualStudio.Shell.Immutable.10.0 assembly. On a machine with Visual Studio 2010 installed, there isn’t a problem loading it since the assembly is installed to the GAC. However, on our build server, the assembly is not in the GAC since Visual Studio 2010 isn’t installed.

In order to allow CreatePkgDef.exe to find the assembly, we can simply add a copy of this binary in our vssdk_tools\bin directory. Do the following:

1. Copy Microsoft.VisualStudio.Shell.Immutable.10.0.dll from our project binaries folder to vssdk_tools\bin.
2. Add this new file to source control and checkin

Step #8: Add the VSIXManifestSchema.xsd to allow VsixManifest validation on the build server

This task fails because the build task can’t locate the XML schema file for VSIXManifest to do schema validation. We could just switch this task off, but since it’s a good idea to run this validation when we build, let’s do what’s necessary to enable validation. There is an MSBuild property we can set to override this location on our build server. Simply add the following property to the first <PropertyGroup>:

<VsixSchemaPath>$(VsSDKInstall)\schemas\VSIXManifestSchema.xsd</VsixSchemaPath>

Of course, we also need to add the schema file to this directory:

1. Copy the VSIXManifestSchema.xsd file from “%ProgramFiles%\Microsoft Visual Studio 10.0\Xml\Schemas” to vssdk_tools\schemas.
2. Add VSIXManifestSchema.xsd to source control

Let’s try again and see where we are:

Step #9: Disable deployment to the Experimental Instance

To make ‘F5’ debugging work without any work by the user, by default, there are some additional targets that run in Microsoft.VsSDK.Common.targets. These targets ‘deploy’ your extension’s files to the Experimental instance for debugging. Since this scenario doesn’t make sense for our build server, we should disable it.

The Visual Studio SDK includes a project property page for configuring this property:

Note that you will probably want a separate build configuration for your build server (to set this property to false) so that developers can still easily debug their package on a client machine.

If you prefer to configure this directly in your project file instead of using the UI, use the following property:

<DeployExtension>False</DeployExtension>

Let’s see how this affects our build:

Success!!

Hooray! If I check the build output directory, we now see that we have a VSIX file that was built on the server:

Microsoft Visual studio is waiting for an internal operation to complete. If you regularly encounter this delay during normal usage, please report this problem to Microsoft.

Well, now you actually can report these problems to Microsoft…automatically. Here’s a description of the extension from the Visual Studio Gallery page:

“We’re constantly working to improve the performance of Visual Studio and take feedback about it very seriously. Our investigations into these issues have found that there are a variety of scenarios where a long running task can cause the UI thread to hang or become unresponsive. Visual Studio PerfWatson is a low overhead telemetry system that helps us capture these instances of UI unresponsiveness and report them back to Microsoft automatically and anonymously. We then use this data to drive performance improvements that make Visual Studio faster.

Here’s how it works: when the tool detects that the Visual Studio UI has become unresponsive, it records information about the length of the delay and the root cause, and submits a report to Microsoft. The Visual Studio team can then aggregate the data from these reports to prioritize the issues that are causing the largest or most frequent delays across our user base. By installing the PerfWatson extension, you are helping Microsoft identify and fix the performance issues that you most frequently encounter on your PC.”

I’d strongly encourage you to install PerfWatson if you’re frustrated with seemingly random UI hangs in Visual Studio. This extension won’t fix the issues, but it will help us see where the real-world responsiveness issues are to help improve future releases.

Check it out if you’re interested in distributing custom content (not necessarily code) as a Visual Studio extension.

Download Visual Studio 2010 (MSDN subscribers only)

Download Visual Studio 2010 SDK

The Visual Studio Industry Partner (VSIP) team has also posted a slew of videos showing off some of the great add-on products that bring additional functionality to the new IDE.

Enjoy, and do please let us know what you think via email, forums, blogs, Twitter, and Microsoft Connect!

Last week, I published a post on the Visual Studio Blog discussing how you could build templates from source files and package them up in a VSIX container using the new templates in the Visual Studio 2010 SDK.

We’ve been hearing questions about how to take an existing project (updated from Visual Studio 2008, still using ZipProject/ZipItem) and include the built zip files in the VSIX container.

Unfortunately, this doesn’t happen automatically for you. The reason is that the zip files are not specified as input files for building the VSIX container in the VSSDK build targets.

Fortunately, since MSBuild is a highly extensible system, we can make up for this with a little bit of project customization. Simply add the following to your C#/VB project file to get your existing templates included in the VSIX container:

<PropertyGroup>
    <GetVsixSourceItemsDependsOn>$(GetVsixSourceItemsDependsOn);GetVsixTemplateItems</GetVsixSourceItemsDependsOn>
</PropertyGroup>
<Target Name="GetVsixTemplateItems" DependsOnTargets="ZipProjects;ZipItems">
    <ItemGroup>
        <VSIXSourceItem Include="@(IntermediateZipItem)">
            <VSIXSubPath>ItemTemplates\%(IntermediateZipItem.Language)\%(IntermediateZipItem.OutputSubPath)\%(IntermediateZipItem.Culture)</VSIXSubPath>
        </VSIXSourceItem>
        <VSIXSourceItem Include="@(IntermediateZipProject)">
            <VSIXSubPath>ProjectTemplates\%(IntermediateZipProject.Language)\%(IntermediateZipProject.OutputSubPath)\%(IntermediateZipProject.Culture)</VSIXSubPath>
        </VSIXSourceItem>
    </ItemGroup>
</Target>

You will also need to add the following lines (as appropriate) to your source.extension.vsixmanifest:

<Content>
    <ProjectTemplate>ProjectTemplates</ProjectTemplate>
    <ItemTemplate>ItemTemplates</ItemTemplate>
</Content>

These lines each declare a root folder in your VSIX file that VS should examine for template files. Project template zip files will be placed in the ProjectTemplates folder inside the VSIX file. Item template zip files will be placed in (you guessed it)…the ItemTemplates folder inside the VSIX file.

One nice thing about this solution is that you can easily switch between targeting 2008 and 2010 by simply changing the startup project between the package project and the VSIX project.

Setup machine with VS 2008 SP1 + VS2008 SDK 1.1 + VS2010 Beta 2 + VS2010 Beta 2 SDK

1. In VS 2008 : create a VB or C# VSPackage
   • (optionally) Build/F5 to verify that it builds/loads as expected in 2008 Experimental Hive
   • Close VS 2008 Instances
2. Launch VS 2010, open the solution, and proceed with project upgrade wizard
3. Unload the VSPackage project, edit the project file, and add the following target after the Imports statements at the bottom:

   <Target Name="PkgdefProjectOutputGroup" Outputs="@(PkgdefOutputGroupOutput)">  
     <RegPkg ItemToRegister="$(TargetPath)"  
       ProductVersion="$(TargetVSVersion)"  
       RegistrationRoot="$(__InternalTargetRoot)"  
       SDKVersion="$(VsSDKVersion)" 
       UseCodebase="true" 
       OutputFile="$(IntermediateOutputPath)$(TargetName)_.pkgdef"
       Unregister="false" 
       UseVS2005MPF="$(__InternalUseMPF80)" />     
     <ItemGroup> 
       <_PkgdefOutputGroupOutput Include="$(IntermediateOutputPath)$(TargetName)_.pkgdef" /> 
     </ItemGroup> 
     <ItemGroup> 
       <PkgdefOutputGroupOutput Include="@(_PkgdefOutputGroupOutput->'%(FullPath)')" /> 
     </ItemGroup> 
   </Target>

4. Reload the VSPackage project
5. Add a VSIX Project to the solution (From Visual C#\Extensibility or Visual Basic\Extensibility in the New Project Dialog)
   • Note: You do not have to distribute your package in a VSIX container. This is simply a requirement for registering and debugging in the VS 2010 Experimental Instance.
6. Add a Project Reference from the VSIX Project to the VSPackage project
7. Unload the VSIX project, edit the project file, and add the following inside the <ProjectReference> node:

   <IncludeOutputGroupsInVSIX>
     BuiltProjectOutputGroup;  
     PkgdefProjectOutputGroup  
   </IncludeOutputGroupsInVSIX> 
   <IncludeOutputGroupsInVSIXLocalOnly> 
     DebugSymbolsProjectOutputGroup 
   </IncludeOutputGroupsInVSIXLocalOnly>

8. Reload the VSIX Project
9. Right-click the VSIX Project node and “Set as Startup Project” (if you wish to run/debug the package under VS2010)
10. F5 to debug the package running in the VS2010 Experimental Instance with VS2010

Do not ever edit a key that ends in “_Config”

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0

This key contains your user-specific settings and works the same as it has in prior VS releases. This could be things like pointers to your default project locations, window layout data, etc… In general it is OK to make tweaks to this key. The worst thing that could happen is that you end up corrupting your user settings. Deleting the key will cause the first-launch “Please choose a profile” dialog to come up the next time you launch Visual Studio.

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config

If you examine the contents of this key, you’ll see that it contains the configuration data for VS 2010. This includes things like package registration, project system registration, editor factory registration, etc… You may also notice that the contents are very similar to HKLM\Software\Microsoft\VisualStudio\10.0.

You can think of the _Config key as a volatile cache of VS’s configuration data for a particular user. It is simply the combination of HKLM\Software\Microsoft\VisualStudio\10.0 and any pkgdef files coming from VS extensions (either from Common7\IDE\Extensions or %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions).

(A previous post discussed how the Experimental Instance works.)

If you edit a key in 10.0_Config, Visual Studio will (quite possibly) delete it on startup.

If you need to change a value, always do one of the following:

1. Edit the value under HKLM\Software\Microsoft\VisualStudio\10.0
2. Edit (or add) a pkgdef file for the extension in question (For managed VSPackages, this is likely editing/adding a RegistrationAttribute in your code).

There are also several other related announcements around RTM dates, pricing, and SKU’s:

Soma’s Announcement
Ars Technica : Visual Studio 2010 simplified to four SKUs, Beta 2 arrives