Reported by Carlos Quintero Mar 31, 2017 at 04:39 PM windows 10.0visual studio 2017

When you create a VSIX project with a VS package on a development machine with VS 2017 (where it builds successfully) and you move or download the project on a build server which has installed Build Tools 2017 but it doesn't have installed VS 2017, the project fails to build with error:

error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\VSSDK\Microsoft.VsSDK.targets" was not found.

while you could think that it is because the VS SDK is not installed, neither Build Tools 2017 includes it as workload nor it is available as standalone setup. But that's fine since the VS SDK is provided as a NuGet package for the VSIX project, so the build should succeed. There is a problem in the MSBuild scripts.

Steps to reproduce the problem:

1) On the development machine with VS 2017 Community edition:

• Ensure that the workload ".NET Desktop development" is installed (it includes ".NET Framework 4.6.1 development tools")

• Ensure that the workload "Visual Studio extension development" is installed

• Click File > New > Project

• In the New Project dialog, select .NET Framework 4.6.1 in the combobox at the top

• Select the template Visual C# > Extensibility > VSIX Project

• Right-click the VSIXProject1 project in the Solution Explorer and click Add > New Item...

• Select the template Visual C# Items > Extensibility > Visual Studio Package

• Remove the following references (not required and that would cause a warning on the build server): EnvDTE, EnvDTE80, EnvDTE90, EnvDTE100, Microsoft.VisualStudio.CommandBars

• Right-click the VSIXProject1 project in the Solution Explorer and click Unload Project

• Right-click the VSIXProject1 project in the Solution Explorer and click Edit Project

• Inside the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> element add the following (to avoid deploying the extension in Release configuration later on the build server, where VS is not installed):

  <DeployExtension>False</DeployExtension>

• Save the changes

• Right-click the VSIXProject1 project in the Solution Explorer and click Reload Project

• Build the solution in Release configuration. It builds successfully.

• Open the folder of the project and delete the bin and obj folders

• Zip the folder with the solution (attached to this bug report)

2) On the Build server:

• Install Build Tools 2017 (do not install VS 2017)

• Ensure that the following indivual components are installed:

  .NET Framework 4.6.1 SDK .NET Framework 4.6.1 Targeting Pack

• Copy the zip file from the development machine and unzip it

• Create a .cmd file in the folder with the project with these statements (included in the file attached to this bug report):

  "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe" "VSIXProject1.sln" /verbosity:normal /p:Configuration=Release

PAUSE

• Execute the .cmd file. You get:

error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\VSSDK\Microsoft.VsSDK.targets" was not found. Also, tried to find "VSSDK\Microsoft.VsSDK.targets" in the fallback search path(s) for $(VSToolsPath) - "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe.Config". Confirm that the path in the <Import> declaration is correct, and that the file exists on disk in one of the search paths.

FWIW, if you edit this file:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Microsoft.VisualStudioVersion.v15.Common.props

and comment this code:

<!-- <PropertyGroup> <VisualStudioVersion>15.0</VisualStudioVersion> <VSToolsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> </PropertyGroup> -->

then the .cmd file builds the VSIX project sucessfully, but the build should work flawlessly without this workaround.