Update MSBuildWorkspace to work with MSBuild 15.0

[tmeschter]

MSBuildWorkspace, along with its unit tests and other tests that happen to use it, directly or indirectly depend on being able to find the location of MSBuild binaries, settings, and targets in the registry. This was fine for MSBuild 14.0, but no such information is available for 15.0 (by design).

We need to update MSBuildWorkspace to use some sort of self-contained MSBuild-in-a-package once it exists, and updated all the related tests.

Until we do this, MSBuildWorkspace and its tests won't be able to run on a system that only has Dev15.

[Pilchie]

Alternatively, we could try writing some code to enumerate the installed instances of 15.0 versions instead of relying on it being in the gac.

[tmeschter]

Even better.

[tmeschter]

@Pilchie Isn't there a NuGet package to help do that?

[Pilchie]

See RoslynTools.Microsoft.LocateVS.

[Pilchie]

You're already working on this, right?

[tmeschter]

Yep. In progress.

[Pilchie]

I think @mattwar is working on this now.

[mattwar]

This is working now in dev15 RTM.

You need to have the application using MSBuildWorkspace also include the Microsoft.Build and Microsoft.Build.Tasks.Core packages from nuget (both version 15.1.0-preview-000458-02 or newer) and have your app.config file include the newer msbuild redirects that can be found in the msbuild.exe.config for msbuild 15.

[sanilpaul]

@Pilchie @mattwar
I think the exception am getting is related to this issue. let me know if its not and I need to open up a different issue.

using msbuildworkspace throws exception with VS Enterprise 2017 version 15.3. It did work fine prior to the upgrade. I would really appreciate any help. We are using roslyin to convert the whole code base into using async -await. The exception am getting is

InvalidProjectFileException: The tools version "15.0" is unrecognized. 
Available tools versions are "14.0", "2.0", "3.5", "4.0".  

Program.Main

var activeWorkspace = MSBuildWorkspace.Create();
activeWorkspace.WorkspaceFailed += (s, e) => { Console.WriteLine(e.Diagnostic); };
var result = activeWorkspace.OpenSolutionAsync(SolutionPath).Result;

This is the app.config of the roslyn console project.

<dependentAssembly>
        <assemblyIdentity name="Microsoft.Build" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0"/>
      </dependentAssembly>

[Pilchie]

I'm pretty sure that MSBuild was reved in 15.3, and those binding redirects probably need to be updated.

[sanilpaul]

Thanks for the quick response. I added the binding redirects after looking into the C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe.config . Any pointers on how to proceed?

[rainersigwald]

No new binding redirects should be needed for MSBuild 15.3 compatibility (we left the assembly version the same to avoid the need for them).

@sanilpaul what you're seeing sounds very similar to dotnet/msbuild#2369; let's track it there.

[sanilpaul]

@rainersigwald I appreciate your quick response. Looking forward to the fix.

[sanilpaul]

@Pilchie @rainersigwald @DustinCampbell

I used the msbuild in the preview package described in dotnet/msbuild#2369 to get past the msbuild version issue. I got past the version issue described earlier in the thread. However, I am running into another issue similar to what is described in #18633.

Do any of the Roslyn code analysis package have to change? Any pointers on how to proceed will be really helpful. I am stuck now.

These are the error details.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets: (84, 5): The "Csc" task failed unexpectedly. System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.CodeAnalysis.BuildTasks.Csc.AddResponseFileCommands(CommandLineBuilderExtension commandLine) at Microsoft.CodeAnalysis.BuildTasks.ManagedCompiler.GenerateResponseFileCommands() at Microsoft.Build.Utilities.ToolTask.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()

These are the packages I have
"Microsoft.Build" version="15.5.0-preview-000074-0946838"
"Microsoft.Build.Framework" version="15.5.0-preview-000074-0946838"
"Microsoft.Build.Utilities.Core" version="15.5.0-preview-000074-0946838"
"Microsoft.CodeAnalysis" version="2.3.1"
`

[aggieben]

I am also experiencing what @sanilpaul described (Csc task failed) and can reproduce in LinqPad with a minimal target solution (attached). I'm using released versions of the packages.

roslyn-15056-repro.zip

[sanilpaul]

@aggieben I got it resolved by following the last comment in dotnet/msbuild#2369 . Before creating the workspace, set the environment variable through code. Basically, you would do

Environment.SetEnvironmentVariable("VSINSTALLDIR", visualStudio2017.GetInstallationPath());
Environment.SetEnvironmentVariable("VisualStudioVersion", "15.0");
var activeWorkspace = MSBuildWorkspace.Create();
activeWorkspace.WorkspaceFailed += (s, e) => { Console.WriteLine(e.Diagnostic); };
var result = activeWorkspace.OpenSolutionAsync(SolutionPath).Result;