msbuild nuget package unable to open vs2017 csproj files

[weltkante]

I'm referencing the nuget packages Microsoft.Build and Microsoft.Build.Tasks.Core. It doesn't matter if I chose stable or prerelease, both versions run into the same error.

I'm trying to open a csproj file for evaluation:

var projectFile = @"C:\projects\test\test.csproj";
var project = new Microsoft.Build.Evaluation.Project(projectFile);
var projectName = Path.GetFileNameWithoutExtension(projectFile);
var outputFile = project.GetPropertyValue("TargetPath");
var outputName = Path.GetFileName(outputFile);

I'm getting Microsoft.Build.Exceptions.InvalidProjectFileException: 'The tools version "15.0" is unrecognized. Available tools versions are "12.0", "14.0", "2.0", "3.5", "4.0".'

When searching the web for this error message I'm only coming up with things related to the VS 2017 installation and how to look up the msbuild packaged with it; unfortunately this doesn't help me with my instance of the exception because I'm invoking msbuild as a library and not as a process.

Do I have to tell the nuget assemblies where the VS 2017 installation is? How do I do this? (I was assuming the nuget assemblies can work stand alone, but if a VS installation is required that works too, it's just not discoverable for me what to do here.)

[Kryptos-FR]

I'm having a similar issue. I noticed that it usually happens when there are multiple side-by-side installation of Visual Studio 2017 (e.g. stable release and preview, or Community and Pro) and/or Build Tools for Visual Studio 2017 (as a nickname "2" installation).

Our users complain that they can't build their project with our system anymore but it looks like the issue is in Microsoft Build itself. This is a serious blocker and I hope that it can be fixed ASAP.

[Kryptos-FR]

Seems to be related to https://github.com/Microsoft/msbuild/issues/2427.

Isn't this code supposed to find all installed and supported versions of MSBuild?

var projectCollection = new Microsoft.Build.Evaluation.ProjectCollection();
var toolsets = projectCollection.Toolsets; // is missing 15.0
var project = new Microsoft.Build.Evaluation.Project(null, null, projectCollection); // throws an exception here
// same happens with default constructor of project:
var project = new Microsoft.Build.Evaluation.Project();

In my case, after updating to Visual Studio 15.3, this doesn't find the latest (15.0) tools version. It was working fine before the update. Seems to me that this can break at any time after an update. This is a critical issue. cc @rainersigwald

[rainersigwald]

Do I have to tell the nuget assemblies where the VS 2017 installation is? How do I do this?

Ideally you wouldn't have to, but it does look like something is wrong with our code to support that.

2030 tracks us providing an easy way to do that. There's a link from there to https://github.com/Microsoft/msbuild/issues/1784#issuecomment-293402946, which links to https://github.com/debanne/dotnet-builder/pull/1 where @AndyGerlicher wrote some example code to find and load MSBuild.

I'll see if I can reproduce this to figure out what's going on (and probably some other workarounds).

[rainersigwald]

Related (via https://github.com/dotnet/docfx/issues/1969#issuecomment-322764421): http://www.michalkomorowski.com/2017/04/why-i-hate-roslyn-even-more.html

[weltkante]

I probably should have noted that in my original report, but I'm already using the Microsoft.VisualStudio.Setup.Configuration.Interop nuget library to figure out which VS 2017 versions are installed. So figuring out where VS or MSBuild is located is not the problem, I'm already doing that.

My problem is that I'm linking against the MSBuild nuget package and want to evaluate projects in-process programmatically without invoking a separate MSBuild process (which would make no sense anyways since I'm extracting information from the projects, not running a build).

So, assuming I already have the information where v15 is located, any idea how I can pass this on to MSBuild? Or is this impossible and I have to wait for a fix in the nuget MSBuild package?

(Sorry if this information was in the linked issues, I tried looking through them, but couldn't find anything related.)

[rainersigwald]

@weltkante Yes, if you have that information already, there's an easy workaround.

Set the environment variables VSINSTALLDIR and VisualStudioVersion before calling into MSBuild APIs.

I just confirmed on my machine with this hardcoded value on top of your example code:

Environment.SetEnvironmentVariable("VSINSTALLDIR", @"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community");
Environment.SetEnvironmentVariable("VisualStudioVersion", @"15.0");

The problem is arising because MSBuild attempts to build from the installed version of Visual Studio where possible, but we're failing to locate it now (still not sure why; continuing to look). Setting those environment variables lets an alternate codepath through the find-toolset code take over.

[rainersigwald]

Ok, here's the source of the problem:

https://github.com/Microsoft/msbuild/blob/ab090d1255caa87e742cbdbc6d7fe904ecebd975/src/Shared/BuildEnvironmentHelper.cs#L232-L235

The returned instance of VS (on this machine) has version 15.3.26730.3, which doesn't match CurrentVisualStudioVersion which is 15.0.

Need to track down an Update 2 machine to see if this is a recent change in the return value that we need to ping the setup folks about (I don't see how it could have been working otherwise).

Also need to make our code more robust. Not quite sure how yet.

[weltkante]

Your example didn't work for me, but looking at the source, trying to set MSBUILD_EXE_PATH worked for me (using the latest nuget package 15.3.409):

Environment.SetEnvironmentVariable("MSBUILD_EXE_PATH", @"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe");

No idea why it doesn't pick up the other two variables you used.

(Also, for the record, I created the issue when I was on v15.2 - so this has been broken before the update to v15.3 ~ at the point where I created the issue I had no preview installed, but I did have a preview a few weeks/months before writing that code; not sure if it was a 15.2 or 15.3 preview though)

[weltkante]

Ok figured it out why your variables didn't work for me.

Apparently having msbuild anywhere in the process name will freak out msbuild ;)

https://github.com/Microsoft/msbuild/blob/ab090d1255caa87e742cbdbc6d7fe904ecebd975/src/Shared/BuildEnvironmentHelper.cs#L327-L334

(Notice the IndexOf() >= 0 part)

I had named my sandbox project to repro the bug MsBuildIssueRepro and apparently that makes MsBuild think my process is a full MsBuild installation.

Renaming the project allows your variables to work, too.

Reading through the source I believe most of the TryFromXXX Methods should check if their guess was correct before returning a non-null value. Otherwise they are ending the chain of try-methods early with a wrong guess.

[rainersigwald]

@weltkante "MSBuild libraries get confused if your program has msbuild in its name" is #2194. We discovered this week that it's bitten every member of the core MSBuild team for exactly this kind of sample project. You nailed the cause!

Glad to hear setting the environment variables worked for you. I should also note that if you run your application from a "Developer Command Prompt for VS2017" it'll set those for you, so any MSBuild API consumer should work from there.

[rainersigwald]

Ok, I set up a VM with different VSes:

And our enumeration code returns:

Count = 3
 {Microsoft.Build.Shared.VisualStudioInstance}
  "Visual Studio Community 2017"
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community"
  {15.2.26430.4}
 {Microsoft.Build.Shared.VisualStudioInstance}
  "Visual Studio Professional 2017"
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional"
  {15.3.26730.3}
 {Microsoft.Build.Shared.VisualStudioInstance}
  "Visual Studio Enterprise 2017"
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise"
  {15.0.26403.0}

So it does look like this broke with 15.2.

[Kryptos-FR]

@rainersigwald As far as I know us final user don't have a way to chose which version of VS we want to install. I know it is not directly related to MSBuild but it would be nice to ask the VS team to offer an option in the VS installer. When the whole team is still on a previous version (say 15.2) and you have a newcomer you want him or her to also use the same version.

Answering your question on #2427:

Please include details about how you're referencing MSBuild and what you deploy with your application.

We ask our user to either install VS or the Build Tools. We actually have a step in our installer setup that will call the VS installer in case none are detected (using vs_buildtools.exe that is deployed with our setup). Then from our code we just use the API from the several Microsoft.Build nuget packages to either create or load .props or .csproj using similar code than https://github.com/Microsoft/msbuild/issues/2369#issuecomment-322660482. So we don't deploy MSBuild ourselves (and as you said in the other issue we shouldn't have to do it), we just include the Microsoft.Build dlls with our application.

Also I'll have to check but I'm not sure if Microsoft.VisualStudio.Setup.Configuration.Interop is able to return the instance(s) of Build Tools. We were not using this library to find out MSBuild path, only the installed version of VS so that we can provide a built-in option to open the project with VS.

So it does look like this broke with 15.2.

It is a bit weird. It still works at home for me with 15.2. But a coworker (who still have 15.2) did modify its VS install to include other packages (like support for UWP and such) and it started to fail. It also work on a VM with a fresh install of everything (VS or Build Tools) until 15.2 (included). But I did notice that sometimes it will start to fail when more than one instance was installed side by side (not sure why). So maybe Build Tools for 15.2 was still returning the correct version at some point.

[parkycai]

@rainersigwald When will this fix be applied to nuget package? thx!

[dasMulli]

Maybe somehow related: What happens if a program using the vs shell like the VS 2017 Team Explorer is installed that isn't really a complete VS / build environment? e.g. https://stackoverflow.com/questions/45760787 sees this error:

MSBuild auto-detection: using msbuild version '15.3.409.57025' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\TeamExplorer\MSBuild\15.0\bin'.

[artiomchi]

A potentially related issue.. Once upgraded to 15.3, MSBuild can't properly open 2017 csproj files. The error we're getting is:

Failure: Msbuild failed when processing the file 'D:\Development\R4MVC\src\R4MvcHostApp\R4MvcHostApp.csproj' with message: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. D:\Development\R4MVC\src\R4MvcHostApp\R4MvcHostApp.csproj

Running process monitor, I can see that the app is trying to access [path_to_running_exe]\Sdks\Microsoft.NET.Sdk.Web\Sdk and is obviously not finding that. Adding various combinations of environment settings from the comments above have caused it to crash with several different error messages, but none of the suggestions have ultimately fixed the issue.

I'm perfectly happy to provide any help in tracing this, as we have this replicated on multiple machines, and by multiple users.

[rainersigwald]

@artiomchi Yes, that sounds related. Can you share the errors when you set VSINSTALLDIR and VisualStudioVersion? I expect that to work.

[rainersigwald]

@dasMulli Filed #2460 for Team Explorer, since it's not caused by the same root cause as this is.

[artiomchi]

@rainersigwald Ahh.. During my long attempts to make it work (before I found this issue), I also installed the Microsoft.Build.Runtime NuGet package, due to it's description:

This package contains the runtime of MSBuild. Reference this package only if your application needs to load projects or execute in-process builds.

This package seems bundled with it's own MSBuild, and that build also failed to find Microsoft.NET.Sdk.Web (same error whether I used this package or when I just used Microsoft.Build and Microsoft.Build.Tasks.Core)

Setting the VSINSTALLDIR and VisualStudioVersion variables with the Runtime package installed made no difference. Setting the MSBUILD_EXE_PATH to gave me the following error:

Failure: Msbuild failed when processing the file 'D:\Development\R4MVC\src\R4MvcHostApp\R4MvcHostApp.csproj' with message: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\15.0\Microsoft.Common.props" was not found. Also, tried to find "15.0\Microsoft.Common.props" in the fallback search path(s) for $(MSBuildExtensionsPath) - "C:\Program Files (x86)\MSBuild" . These search paths are defined in "D:\Development\R4MVC\src\R4Mvc.Tools\bin\Debug\net462\dotnet-r4mvc.exe.Config". Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths. C:\Program Files\dotnet\sdk\2.0.0\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props

When I removed the Runtime package, leaving just the Microsoft.Build and Microsoft.Build.Tasks.Core packages installed, and set VSINSTALLDIR to the VS install path (didn't even need the VisualStudioVersion in my case), the project loaded successfully. So this is definitely the issue that we were encountering, and the Runtime package has a potentially linked but also separate issue that sent me looking in the wrong direction >_<

[rainersigwald]

@artiomchi I can totally understand how that would be tempting! Can you comment on the wording in #2461?

[Kryptos-FR]

I was able to make it work by setting the VSINSTALLDIR and VisualStudioVersion. Although there was a caveat that I was not expecting (but which still makes sense somehow): you need to set those variables before calling any of the Microsoft.Build API (especially ProjectCollection) otherwise the list of toolsets is cached and you will not be able to find the one for "15.0" after that.

This means that in order to do it properly one has to follow these steps in order:

1. List all instances of Visual Studio installed using Microsoft.VisualStudio.Setup.Configuration
   • The path can be retrieved from ISetupInstance2.GetInstallationPath()
   • Note that this also lists Build Tools for Visual Studio which is perfect in my case
2. Set the environment variables

   Environment.SetEnvironmentVariable("VSINSTALLDIR", installationPath);
   Environment.SetEnvironmentVariable("VisualStudioVersion", @"15.0");

3. Start using Microsoft.Build API, for example:

   var projectCollection = new Microsoft.Build.Evaluation.ProjectCollection();
   if (projectCollection.GetToolset("15.0") == null)
   {
   throw new Exception("MSBuild 15 not found");
   }

   In case you need the full path to MSBuild.exe it should be in Path.Combine(installationPath, "MSBuild", "15.0", "Bin").

Note: it is still going under some testing but it is my hope that this will work for the time being, until the fix is released in the next MSBuild.

[rainersigwald]

@Kryptos-FR Yes, that's exactly right. We're working on #2030 to provide a NuGet package that makes that easier to do (and includes loading the MSBuild assemblies from the same installed VS).

[jairbubbles]

In my case I need my library to work on computers which do not have VS2017 installed so I tweaked a little bit the workaround. I'm sharing it here in case it helps others:

private static void HackForVs2017Update3()
{
    var registryKey = $@"SOFTWARE{(Environment.Is64BitProcess ? @"\Wow6432Node" : string.Empty)}\Microsoft\VisualStudio\SxS\VS7";
    using (RegistryKey subKey = Registry.LocalMachine.OpenSubKey(registryKey))
    {
        string visualStudioPath = subKey?.GetValue("15.0") as string;
        if (!string.IsNullOrEmpty(visualStudioPath))
        {
            Environment.SetEnvironmentVariable("VSINSTALLDIR", visualStudioPath);
            Environment.SetEnvironmentVariable("VisualStudioVersion", @"15.0");
        }
    }
}

Obviously I won't be able to load 15.0 projects in this case.

[rainersigwald]

@jairbubbles The VS setup team would rather you use their API than look in the registry like that, for robustness.

[rainersigwald]

Packages versioned 15.5.0-preview-000072-0942130 have been published to our private feed that contain this fix, if anyone wants to experiment with them.

[jairbubbles]

@rainersigwald Agreed but it's a hack so I wouldn't add a new dependency just for that. Anyway my previous attempt at doing this the clean way using their API was not very succesful but I'd give it another shot. And I still feel like it's over complicated.

(I'm not sure I can access the private feed.)

[rainersigwald]

The feed should be open to everyone, but you have to explicitly add it to your nuget.config (and consume prerelease MSBuild).

[artiomchi]

@rainersigwald @jairbubbles

The link to the feed should be: https://dotnet.myget.org/gallery/msbuild The link you want to add to VisualStudio (or nuget.config) is: https://dotnet.myget.org/F/msbuild/api/v3/index.json

[jairbubbles]

Thx @artiomchi !

I can confirm you that with version 15.5.0-preview-000072-0942130 I do not need the hack anymore.

Any chance to get this in a 15.3 patch?

[artiomchi]

@jairbubbles btw, you can have it working with the current build as well. Here's how I handled it: https://github.com/T4MVC/R4MVC/commit/ae2fd5d8f3ab60708419d37c8a42d237d86d3061#diff-89dd7d1659695edb3702bfe879b34b09R61

[jairbubbles]

@artiomchi I believe your fix won't work if the user doesn't have Visual 2017 installed.

[artiomchi]

@jairbubbles Oh, for sure. But isn't it required to open the vs2017 csproj files anyway? ;)

The project I linked is only relevant for AspNetCore projects, so that's not an issue, plus it's only temporary until the patch to msbuild goes into the stable channel

[jairbubbles]

@artiomchi Yes but in my case it does as the lib I'm working on is just a wrapper over msbuild so it must works on all PC. Clearly with no Visual installed it will most likely fail on all .csproj.

[artiomchi]

@jairbubbles Ahh, right.. I see your point.. But are you sure it won't work? After all, if VS 2017 (or the latest Build tools) are not installed, my script won't change anything (which is the expected behaviour anyway), and it will fall back to the default msbuild, which only opens the old csproj files.

If you want to open the vs2017 build files, you need either the latest build tools or the new VS installed, at which point my snippet will just add the ENV variable.

So that should cover all bases, no?

In any case, with the latest MSBuild packages available in MyGet, it might just be more preferable to use them anyway :D

[sanilpaul]

@rainersigwald I used the msbuild in the preview package and am getting this error. I have described what i am trying to do in https://github.com/dotnet/roslyn/issues/15056 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" ` Do any of the Roslyn code analysis package have to change?

[dazinator]

I have tried to use the latest msbuild packages from the myget feed, to build an sdk style csproj file from within an nunit test.

This is the error I am getting:

Target DispatchToInnerBuilds:

  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CrossTargeting.targets(52,5): error MSB4062: The "Microsoft.Build.Tasks.MSBuild" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Could not load file or assembly 'Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

A barebones sample repo showing how to use the msbuild packages to build an sdk style csproj file would be very helpful.. :-(

[dazinator]

Ok resolved the above by adding Microsoft.Build.Tasks.Core nuget package to my project. I then got an error when trying to run the Pack target:

Task "PackTask"

    C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(141,5): error MSB4127: The "PackTask" task could not be instantiated from the assembly "C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting\..\Desktop\NuGet.Build.Tasks.Pack.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'NuGet.Build.Tasks.Pack.PackTask' to type 'Microsoft.Build.Framework.ITask'.

    C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(141,5): error MSB4060: The "PackTask" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.

The error message prompted me to check binding redirects in app.config - was missing a binding redirect for some reason. Adding the folliwng seems to have fixed it:

<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>

[AndyGerlicher]

Just wanted to give an update on this issue. I published a package for a utility helper to find MSBuild.

Package: https://dotnet.myget.org/feed/msbuild/package/nuget/Microsoft.Build.MSBuildLocator Source: https://github.com/Microsoft/MSBuildLocator/

You can look at the sample app that builds in that repo for usage. I tried to make it as simple as possible to query for installed locations and "register" (add assembly resolver). This should allow you to reference our NuGet package for compile time and not have to ship MSBuild binaries with an app that wants to build or evaluate using our API and the installed toolset.

Please do give feedback in that repo if it works or doesn't for your needs. Thanks!

[Edalzebu]

@rainersigwald I tried your solution by doing the next lines on my build

Environment.SetEnvironmentVariable("VSINSTALLDIR", @"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community"); OR Environment.SetEnvironmentVariable("VSINSTALLDIR", @"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools"); Environment.SetEnvironmentVariable("VisualStudioVersion", @"15.0");

Now it seems that am really using MSBuild 15 but for some reason i am getting the next error, any idea why?

Am using MSBuild API

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(751,5) (MSBuild):The "Microsoft.Build.Tasks.Message" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Could not load file or assembly 'Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

EDIT: Something i noticed is that the files in that directory actually have Version 15.3... does it has something to do with this error?

[dudikeleti]

Just to say "me too". I am also experiencing the "The tools version "15.0" is unrecognized. Available tools versions are "12.0", "14.0", "2.0", "3.5", "4.0".' issue while using Roslyn's MSBuildWorkspace. The same exact code works fine on a computer with VS2017 Update2, but doesn't work on a computer with VS2017 Update3.

[DustinCampbell]

There are a number of things that might cause this. Last week, I ran into the same error because of https://github.com/Microsoft/msbuild/issues/2194.

[matkoch]

I'm still unsure what to do with:

Microsoft.Build.Exceptions.InvalidProjectFileException : The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\15.0\Microsoft.Common.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:\Program Files\dotnet\sdk\2.0.0\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props

The only response here suggested to set VSINSTALLDIR, which I did. Please note that I'm targeting net461 and netcoreapp2.0. For net461 everything works fine, while the other fails.

[mdegroux]

I'm also facing this problem. Do you know when the next release of MsBuild will be available?

[Vannevelj]

Just wanted to chime in here that the two environment variables fixed my issues. I am loading two class libraries, one .NET and one .NET Core csproj style (but both targetting net462) , in an MSBuildWorkspace to use with Roslyn.

Before adding the environment variables the projects got added but there would be no syntax trees, documents or diagnostics. I could see in the workspace its Diagnostics property that the SDK 'Microsoft.NET.Sdk' wasn't found for the .NET core project and the Tools 15.0 version was not found for the .NET projects. After adding the two environment variables they all resolved flawlessly.

PS: This was done in a minimalized test project. In the original project I also had web applications which had their own specific error, namely:

Msbuild failed when processing the file 'C:\Source\MySite.csproj' with message: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:\Source\MySite.csproj

This was also automatically resolved after setting the environment variables.

Future visitors: I'm talking about this comment.

[matkoch]

@rainersigwald any thoughts regarding my comment? Should I create a new issue?

[raffaeler]

With 15.3 everything is broken again even setting the environment variables. What is going on?

[raffaeler]

@rainersigwald FYI I also tried to get from myget the latest msbuild packages with no luck.

Failure Msbuild failed when processing the file 'C:\dev\xyz.csproj' with message: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets: (1601, 5): The "GetReferenceNearestTargetFrameworkTask" task could not be instantiated from the assembly "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'NuGet.Build.Tasks.GetReferenceNearestTargetFrameworkTask' to type 'Microsoft.Build.Framework.ITask'.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets: (1601, 5): The "GetReferenceNearestTargetFrameworkTask" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.

Failure Msbuild failed when processing the file 'C:\dev\xyz.csproj' with message: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets: (84, 5): The "Csc" task could not be instantiated from the assembly "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.Build.Tasks.CodeAnalysis.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.CodeAnalysis.BuildTasks.Csc' to type 'Microsoft.Build.Framework.ITask'.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets: (84, 5): The "Csc" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.

[rainersigwald]

@raffaeler, @matkoch, and others seeing problems--can you describe your situations in a bit more detail, please?

• What VS versions are installed on the machine (output of VSWhere vswhere -all for 2017, plus other versions if applicable)?
• What is the entry point application?
• What is the environment the application is launched from?
• What MSBuild, Roslyn, and VS libraries do you depend on, including versions? Are these dependencies direct?
• What MSBuild assemblies are present in the app folder?
• What environment variables are you specifying, if any?
• What is the exact failure, and what Microsoft.Build* assemblies are loaded at the point of failure (including versions and ideally paths--if you can get them from a debugger easily)?

[raffaeler]

@rainersigwald The version that is not working is 15.5.2 and not 15.5.3 as I wrote before, sorry. With version 15.5.1 I had no apparent problems. I realized something was going wrong because Roslyn began complaining on properties Symbol == null and giving (wrong) SpeculativeSymbol instead. The reason for this is the failure in compiling the solution.

• VS versions. VS2015 RTM and just a single VS2017 version:

  
  Visual Studio Locator version 2.2.11+gf1a9c6c78d [query version 1.14.187.27757]
  Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: a815f38e installDate: 08/08/2017 12:38:40 PM installationName: VisualStudio/15.5.2+27130.2010 installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise installationVersion: 15.5.27130.2010 productId: Microsoft.VisualStudio.Product.Enterprise productPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe isPrerelease: 0 displayName: Visual Studio Enterprise 2017 ...

- The app is a console app created with the .NET desktop version version 4.6.1. Initially I created a .net core app, but I have to go back to 4.6.1 because of problems with roslyn packages

- What is the environment the application is launched from. Visual Studio 2017, debug or the dev cmd prompt (2017)

- Versions. I tried roslyn 2.6.1, 2.6.0 and finally rolled back to 1.3.2 which is the only one that works.
Beyond Roslyn, as suggested by this and other threads, I installed Microsoft.Build, Microsoft.Build.Framework, Microsoft.Build.Tasks.Core, Microsoft.Build.Utilities.Core. The Microsoft.Build.* versions I tried are 15.5.180 and the latest 15.6.0-preview* on myget

- Microsoft Build assemblies in the app folder. Exactly the same of the nuget packages I cited before.

- Environment. I tried with and without the following variables.

        Environment.SetEnvironmentVariable("VisualStudioVersion", "15.0");

        Environment.SetEnvironmentVariable("MSBUILD_EXE_PATH",
            @"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe");

        Environment.SetEnvironmentVariable("VSINSTALLDIR",
            @"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise");

- What is the exact failure, and what Microsoft.Build* assemblies are loaded at the point of failure 
The failures are the ones I wrote in the previous message. 
I could print the errors in the WorkspaceFailed event, which is the same of the Diagnostics property.
The errors are printed/available as soon as the OpenSolutionAsync is executed.

MSBuildWorkspace workspace = MSBuildWorkspace.Create(); workspace.WorkspaceFailed += Workspace_WorkspaceFailed; var solution = await workspace.OpenSolutionAsync(SolutionFile);

As I said, I now downgraded the project to 1.3.2, so it could take some time to make any tests.

[rainersigwald]

@raffaeler Thanks! Unfortunately, I do not see the same thing on my machine, also with 15.5.27130.2010.

My attempt to repro was:

• Create new .NET 4.6.1 project from template.
• Add reference to Microsoft.CodeAnalysis 2.6.1.
• Do an OpenSolutionAsync and some minimal work.

This failed with a similar-but different error:

Msbuild failed when processing the file 'C:\src\RoslynApiConsumer\RoslynApiConsumer\RoslynApiConsumer.csproj' with message: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets: (84, 5): The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.Build.Tasks.CodeAnalysis.dll. Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

That's because I forgot to add binding redirects (as mentioned above in https://github.com/Microsoft/msbuild/issues/2369#issuecomment-327033965). I added this to my app.config:

<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" 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>
<dependentAssembly>
  <assemblyIdentity name="Microsoft.Build.Tasks.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" />
</dependentAssembly>

And loading the projects completes without errors.

Follow-up questions:

• Are you specifying binding redirects?
• What kinds of project(s) are you attempting to load?
• What happens if you build RoslynApiConsumer.zip and run it -- does it still error? If so can you give its output?

[rainersigwald]

(I should also note that most of the team including me is out on vacation until the first week of January, so responses may be delayed, but I want to help you get to the bottom of this.)