We're also affected by this issue. Could someone please offer a workaround until the issue is resolved in the installer?

Seriously guys? This needs a fix. We have several build agents which are managed with puppet and chocolatey. Copying files from here to there is not an option. This needs to work!!!!! No stupid excuses and no workarounds. Nobody needs "Build tools" which do not build! Stop smoking trash.

Please solve this problem: (1) Installing Visual Studio Professional Enterprise (2) Changing the path of 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Sdks' to 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks' (Professional o Enterprise) (3) Build the solution

I agree this is ridiculous: on a fresh TFS 2017 / VS 2017 Build Tool install, you can't build a project which use the new csproj format (it is not limited to Web project). Event copying Sdks folder from a full VS install does not solve the problem.

I have also reported this issue on connect : https://connect.microsoft.com/VisualStudio/Feedback/Details/3133196

There is an open question also on stackoverflow : http://stackoverflow.com/questions/42837264/missing-include-for-netstandard-project-when-building-on-build-server

And finally an issue on github msbuild : https://github.com/Microsoft/msbuild/issues/1697

This is completely blocking us using new .csproj files.

At this point in time, the separate build tools package is unusable in a deployment pipeline.

I remember around year 2000 when .net and c# were quite new things I saw a guy reporting an issue that some critical method of some critical class was clearly not working as intended. Few days later he got an official reply from some M$ engineer: "this method doesn't work. Please don't use it"...
I see that they haven't improved much...

Thank you for your feedback!

Given the state of things right now, this is a pretty complex issue. To do a build, a potentially large set of files are required to be present on your machine for it to work correctly. Our goal is to move more and more of that logic into packages which can be acquired at build time rather than installed by Visual Studio, but that's not always the case today. For the particular issue in this feedback, we have resolved the issue and it will be included in an upcoming release (15.4). This inclusion of NuGet and SDKs as well as other features coming in 15.5 will help us to deliver a base "Build SKU" that will become more and more useful as NuGet packages are available.

Thank you for helping us build a better Visual Studio!

To be honest, The Build Tool should already have it as well as a proper deployment since we all are (hopefully) focusing on a proper DevOps configuration!

The fix for this is now in our latest Visual Studio Preview release. If you'd like to try out the fix, you can access the preview build here: https://www.visualstudio.com/vs/preview