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:

c# 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:DevelopmentR4MVCsrcR4MvcHostAppR4MvcHostApp.csproj' with message: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. D:DevelopmentR4MVCsrcR4MvcHostAppR4MvcHostApp.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:DevelopmentR4MVCsrcR4MvcHostAppR4MvcHostApp.csproj' with message: The imported project "C:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0Bin15.0Microsoft.Common.props" was not found. Also, tried to find "15.0Microsoft.Common.props" in the fallback search path(s) for $(MSBuildExtensionsPath) - "C:Program Files (x86)MSBuild" . These search paths are defined in "D:DevelopmentR4MVCsrcR4Mvc.ToolsbinDebugnet462dotnet-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 Filesdotnetsdk2.0.0SdksMicrosoft.NET.SdkSdkSdk.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");

1. 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 Studio2017ProfessionalMSBuild15.0Bin15.0Microsoft.Common.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:Program Filesdotnetsdk2.0.0SdksMicrosoft.NET.SdkSdkSdk.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:SourceMySite.csproj' with message: The imported project "C:Program Files (x86)MSBuildMicrosoftVisualStudiov15.0WebApplicationsMicrosoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:SourceMySite.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.)

[raffaeler]

Thank you @rainersigwald ... I made many tests by analyzing my test solution with your code.

• your solution worked
• your solution after updating all the latest nuget (not the prerelease) packages worked

so I updated the non-roslyn packages to the latest (the output is similar to this, but I didn't capture the one of my update):

(they are just roslyn dependencies, the only one I directly use is the tuple package)
Then I updated the Roslyn from 1.32 to 2.6.1 and now works.

Now the only difference between mine and your solutions is that I also reference Microsoft.Build.* packages while you don't (should I remove them?)

Where is the wizardry? Is the compilation process dependent from a specific version of system.composition package?

P.S. yes, I have binding redirects in my solution which were automatically updated by the nuget process.

[matkoch]

@rainersigwald my use case is just to evaluate MSBuild properties, like Configuration, TargetFrameworks, PackageReferences, included files, and so on. My goal is that this works cross platform with .NET Framework, Mono, and of course also .NET Core tooling (without any VS installed at all). Roslyn/C# is completely out of scope.

Just a moment ago, I created a simple repro with netcoreapp2.0, references to Microsoft.Build and Microsoft.Build.Utilities.Core and this code:

var projectCollection = new ProjectCollection();
var project = new Project(@"..\ConsoleApp10.csproj",
        new Dictionary<string, string>(),
        projectCollection.DefaultToolsVersion);

var lookup = project.Items.ToLookup(x => x.ItemType, x => x.EvaluatedInclude);

I tried this w/ and w/o binding redirects. Always fails with:

The SDK 'Microsoft.NET.Sdk' specified could not be found.

[matkoch]

Ping @rainersigwald. Could you please also re-open this issue? It is obviously not solved.

[ulrichb]

@rainersigwald This is a blocking issue for me too. /cc @matkoch

[matkoch]

@rainersigwald kindly pinging....

[flagbug]

I'm having the same problem that @matkoch is having. I'm working on a cross-platform tool that analyzes outdated packages (https://github.com/goenning/dotnet-outdated) and really just want to read the package references of a simple project file.

The problem is that this always throws The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. for some reason

[p-kaczynski]

Having same problem, but only when using .netcore2.0, works fine in .net framework.

[p-kaczynski]

Literally changing from <TargetFramework>netcoreapp2.0</TargetFramework> to <TargetFramework>net461</TargetFramework> fixes the issue for me using

<PackageReference Include="Microsoft.Build" Version="15.6.85" />
    <PackageReference Include="Microsoft.Build.Utilities.Core" Version="15.6.85" />

and new Project(path)

[CodeTroopers]

I had the same issue with a TFS Build Agent (Version 2010) after installing Build Tools for Visual Studio 2017 and configuring MSBuild arguments to : /toolsversion:15.0 /property:VisualStudioVersion=15.0.
It seems this registery key is missing : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\15.0 with the string value MSBuildToolsPath and cause the error :

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

[manish10sharma]

Hello I am having the same issue.
MSB4062 The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly C:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0BinRoslynMicrosoft.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 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. MSBuild C:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0BinRoslynMicrosoft.CSharp.Core.targets 52 false Error

Can Anyone tell me solution if found?
I am using 2017 15.8.2 Version.

Please help.
Thanks

[kjkrum]

I'm got the same error when opening the csproj of one project from another project. Both projects were freshly created today in VS2017 15.8.8. Updating to 15.8.9 did not help.

C# using (var col = new ProjectCollection()) { var proj = col.LoadProject(projectFile); // kaboom! }
Installing the latest Microsoft.Build and Microsoft.Build.Utilities.Core from nuget solved the problem. I didn't even need to fiddle around with environment variables. Why does VS still ship with a broken MSBuild?

[weltkante]

@kjkrum

Why does VS still ship with a broken MSBuild?

As far as I know VS no longer ships MSBuild (it ships via nuget). VS has its own private copy of MSBuild which is not exposed to your project build so you can't reference it.

If you reference MSBuild through the GAC or Assembly Reference list (i.e. not through nuget) you likely get some outdated version which previously shipped with the .NET framework or an older VS and thus still is visible there for backwards compatibility.

[rainersigwald]

You can and should use the VS copy of MSBuild, but since it's no longer in the GAC you must locate it. https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application has details on what's required, and https://github.com/Microsoft/MSBuildLocator/ is a package used to make the process easier.

[kjkrum]

@rainersigwald That's an awful lot of dicking around for something that used to be a checkbox.

[aolszowka]

This is still present. The work around provided by @rainersigwald and documented here https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application?view=vs-2017 (specifically using MSBuildLocator.RegisterDefaults();) worked for us.

[kurtnelle]

Any solution for this. I'm having a similar issue with trying to create a Raspberry Pi Blink project. The project creation fails with the error message "Unable to read the project file "Blink12.vcxproj" The tools version "15.0" is unrecognized. Available tools versions are "2.0","3.5","4.0"

[rainersigwald]

@kurtnelle If https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application doesn't help you, please open a new issue with more details about how you're using the API and what's going wrong.

[GeirGrusom]

Seriously this is a huge issue for me. Old version of the libraries don't work with 2019 only systems and new versions doesn't work with 2017 only systems. I even made a shim that would use new versions on systems with 2019 installed but old in 2017 systems. It seemed like it worked but the integration tests that looked like they worked everywhere else fails on the build server. I don't want that stupid hack to begin with and now it unsurprisingly fails in the most important configuration.

I've been struggling with this for almost a month. The error message is non-sensical and unhelpful, and this is obviously a major breaking change in the library.
Why does upgrading to new versions, with no other changes at all, break simply loading the project in 2017? Just calling "LoadFromXmlReader" throws this error. Setting toolsversion and subtoolsetversion seems to have absolutely no effect what.so.ever.

This thing makes me extremely unproductive and it makes me look incompetent.

[rainersigwald]

@GeirGrusom can you please file a new issue, including details on

Old version of the libraries don't work with 2019 only systems and new versions doesn't work with 2017 only systems.

What libraries?

Why does upgrading to new versions, with no other changes at all, break simply loading the project in 2017?

Can you provide more details on exactly how you're loading projects and what the system environment is (upgrading from what to what)?

[GeirGrusom]

I'm very sorry. I was very stressed on friday, but that's no excuse for unprofessional behavior.

Short about the appliation: It's used for building solutions, versioning and running the test suite on them. I would argue the value of this in the first place but that's unfortunately not particularily productive. It first invokes vswhere to find out where Visual Studio is located and uses that to actually build the application. This failed earlier because it wouldn't try to use Visual Studio 2019 if a project was made with 2017 and specified that so I updated the vswhere implementation to find the latest if an exact match could not be found. This seems to work: projects build just fine.

However the issues show up when running the test suites. It uses Microsoft.Build to load the project files in order to find the output DLL files and dependencies the projects might have. On the old version this worked fine for 2017 but in 2019 it gave this odd error:

error MSB1040: ToolsVersion is not valid. The tools version "15.0" is unrecognized. Available tools versions are "2.0", "3.5", "4.0".

Build libraries are Microsoft.Build and Microsoft.Build.Utilities.Core at version 15.9.20.

I tried to just change "tools" version but this error shows up with different versions except if I put 4.0, at which point it tells me that it can't find Microsoft.NET.Sdk. I upgrade to 16.4.0 on both libraries and now it works in 2019, but on systems with 2017 installed I'm back to the drawing board. So I made this shim that will force it on a newer version as explained and now in all environments I've tested it it works but it is hacky and not exactly very maintenable. It also fails to build on the build server with the same error when it tries to run integration tests with this issues error description.

It seems to me that there's some confusion as to what "toolsVersion" actually mean. Take Microsoft.Build.Utilities.ToolLocationHelper.GetPathToBuildTools(string). In the documentation it looks to me like it should return the location of MSBuild, but it doesn't do that at all. Sometimes it seems to return the entry assembly path, and other times .NET Framework paths, and on my development machine it returns exactly what I would expect.

What does toolsVersion mean? Is it CLR version? MSBuild version? Visual Studio version? The documentaiton on MSBuild...Project.LoadFromStream is not exactly helpful as it just says "that's the tools version" more or less. If I state nothing it seems like MSBuild will put toolsversion from the <Project /> element or whatever SDK it ends up loading and that's what's causing this odd error message. Change the toolsversion and it will complain about wrong toolsversions until you hit 4.0, 3.5 or 2.0 at which point it will complain that Microsoft.NET.Sdk could not be found. Is MSBuild doing the wrong thing here, or is the error description wrong?

I'll see if I can make a trivial reproduction.

[GeirGrusom]

Couldn't reproduce the issue in a trivial solution. Only new project does not properly load in VS2019 but I got everything to work on build so I don't think I want to waste anymore of your time on this.

Thanks, and again, sorry.

[rainersigwald]

@GeirGrusom I think you might like to use MSBuildLocator in your application. It handles the scenarios you're currently using VSWhere for, and you should be able to use a single application to load both 2017 and 2019 projects (as long as you reference MSBuild 15.x when you build).