Msbuild: Tracking: .NET Core Sdk in Build Tools Installer

[debanne]

After installing Build Tools for Visual Studio 2017 RC (download URL: vs_BuildTools.exe), MSBuild.exe cannot be directly used because the Sdks are missing. A workaround is to provide them thanks to the MSBuildSDKsPath variable:
$ set MSBuildSDKsPath=C:\Program Files\dotnet\sdk\1.0.0-rc4-004771\Sdks

Are Build Tools supposed to be used for .NET Core?
If this is the case, then the MSBuildSDKsPath variable should be better documented.
If not (because they are replaced by .NET CLI?), it could be mentioned in https://www.visualstudio.com/downloads/#d-build-tools.

[rainersigwald]

No, the Build Tools installer doesn't currently cover .NET Core scenarios. At some point in the future I hope we can have a .NET Core checkbox within it, but that's not done at the moment.

The dotnet SDK installer (with the CLI) doesn't _replace_ the Build Tools installer, but it is the best current analog for it in some situations, like "what should I install on my CI server?" It is reasonable to install both.

/cc @srivatsn

[rainersigwald]

Changing this to a tracking issue for "there should be a .NET Core checkbox in the Build Tools installer". The actual work will probably happen in the internal VS repo.

[rainersigwald]

Related: https://github.com/NuGet/Home/issues/3660 (getting NuGet restore into the Build Tools installer).

[Spongman]

this is terrible. what's the point of the Build Tools installer, if it isn't to install tools required to build .NET projects?

this is a regression, too. building dotnet core apps worked fine with the v14 build tools. again, this is a breakage of an existing, deployed-to-production scenario.

now we have the v15 tools looking for "Sdk.props" in one directory, and the dotnet SDK isntalling it into some completely different directory.

it's as if one hand isn't talking to the other.

really sloppy guys, really sloppy.

[mariusGundersen]

The solution to using msbuild to compile vs2017 csproj files is to not use msbuild, but to use dotnet instead. So on the build server you need ot install the dotnet sdk, since it comes with the sdks needed by the new vs2017 csproj file, and it comes with nuget. The msbuild install does not.

So, instead of

"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe" continuousIntegration.msbuild /t:deploy

Use

"C:\Program Files\dotnet\dotnet.exe" msbuild continuousIntegration.msbuild /t:deploy

[evil-shrike]

What about asp.net core projects targeting .net framework (not .net core). Can such solutions be built with vs2017 built tools?

[mariusGundersen]

Not out of the box. You have to copy/paste the sdk folder from a machine that has vs2017 installed to the ci machine, and then it's probably a good idea to put them in the location where msbuild is looking for them, instead of messing about with environment variables.

[evil-shrike]

it's probably a good idea to put them in the location where msbuild is looking for them

and where is it?

[mariusGundersen]

Copy the contents of this folder:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks

To

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Sdks

[dasMulli]

Instead of copying over the SDK files, you should also be able to set an MSBuildSDKsPath environment variable to your C:\Program Files\dotnet\sdk\1.0.0\Sdk folder in your CI setup (if the CLI is installed).

[ntregillus]

gotta say, msbuild's loose dependencies lead to so many headaches... it looked like the single responsibility principal was getting followed with the independent with the dotnet tools, but we just took a step back to the msblob that rules them all... who decided the csproj solution was fully baked? please tell them this is an absolute pain.

[ghost]

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

[ntregillus]

I think you are missing what the intent of my ask: I shouldn't need visual studio installed on my build machine: I should only need msbuild to build my project, not a full IDE

[ghost]

I agree with you @ntregillus , but for now is the most viable solution. Hope this can help you!

[ntregillus]

unfortunately it doesn't. I do not have enough licenses to install the IDE onto my build machine. Even if I could, I am not an administrator to install software on our build machine....

I will hold off on this nuget packaging for the core library until the standalone build tools can function independent of a IDE install.

[tbolon]

Does this issue also prevent from even building a simple netstandard project (read "a project using the new csproj format") on a build machine without installing vs 2017 enterprise ?

For now, it requires to copy C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks to build server and also C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet to enable /t:Restore target.

[ntregillus]

No, i can still build vs2017 projects, using the msbuild tools. I have a number of .net core web apps that I would like to utilize this functionality for however

[rainersigwald]

There's a reasonably clear path forward here for the 15.3/.NET CLI 2.0 timeframe. MSBuild has implemented SDK Resolvers #2002, which allow MSBuild and Visual Studio to use the .NET Core SDK installed in Program Files. It does require placing a resolver assembly in the MSBuild instance folder, though, and the work to do so even for the Build Tools installer isn't yet completed.

[dasMulli]

Is it still required to have he NuGet VSIX in the build tools to reasonably build for all combinations of packages.config/ProjectReference, classic/SDK-based csproj? While slacking with @tbolon, he mentioned copying C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet was necessary as well to get his build running..

[dasMulli]

Then there is C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\SolutionFile\ImportAfter\Microsoft.NuGet.Solution.ImportAfter.targets as well for restore on solutions to work.. don't know if it's in the build tools but it could be bad if that is out of sync with the individual project's SDK versions

[rainersigwald]

@dasMulli Good point; that will still be required and is tracked by https://github.com/NuGet/Home/issues/3660. I'll continue bugging partner teams about this internally . . .

[Aleksanderis]

For those who thinks that some of us is comparing apples to oranges speaking about VS2017 Builds Tools and dotnet CLI, saying that one is for ".NET Framework" and another is for ".NET Core".. here you are - a real scenario:

• Azure Service Fabric project (*.sfproj, which is actually old-formatted csproj inside).
• It hosts .NET Core project (new-format csproj)

It is maybe not mature enough tech-stack, but it's supported by Microsoft, everything is final version (not alpha/beta/release-candidate), and actually it works in general.

But guess what? This solution is compilable only through VS2017, which in some mysterious way combines both worlds from .NET Core and classic .NET projects. However if you are up to build it without VS2017 (like in CI build server) - then sorry, you have got serious problems. It really looks like left hand doesn't talk with right hand.

Already tried dozen of workarounds - like copying MSBuild/SDKs from VS2017 directly to CI server, and stuff like that, and still no fully working solution. The best solution so far is thanks to person mentioned about MSBuildSDKsPath environment variable - seems it works with VS2017 Build Tools, but still looks like total workaround, which might stop working after next .NET Core SDK version, and we still need to bother CI server administrators to help us fixing the build.

My related registered issue with some more details from Service Fabric perspective - https://github.com/Azure/service-fabric-issues/issues/258

[avikenjale]

@ntregillus , you said, _"No, i can still build vs2017 projects, using the msbuild tools. I have a number of .net core web apps that I would like to utilize this functionality for however"_, do you mean on build server?

[deepak-khopade-isdr]

@ntregillus, @avikenjale : we are using MSBUILD15 (tools & SDK) and not a complete visual studio as we are on Docker containers (Linux) [our build server is Linux, which creates a container from DOCKERFILE we have and then builds & tests the app on that server] and have no issues using it. So how someone can install full VS on non-windows environments just for the sake of build.
Please correct me if I have wrongly understood this.

[utilitydelta]

I had this issue setting up a CI build agent to build a .NET core web app with the .NET full framework, using MSBuild. To fix, I copied the folder 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk.Web' from my laptop to the build server at: 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Sdks\Microsoft.NET.Sdk.Web'

[fenneh]

To mitigate this if using TeamCity set a build parameter of env.MSBuildSDKsPath to C:\Program Files\dotnet\sdk\1.0.4\Sdks

@ntregillus - To get around license requirements you should be able to use VS 2017 Community. I've got to say the state of building .Net is a joke

[ntregillus]

yeah, unfortunately, i do not think the .net team is focusing on build tools, which is unfortunate since the industry is so CI focused these days.

[jetersen]

This is a pain to figure out, when setting up CI!

[livarcocc]

The next version of the BUILD Tools SKU will have an option to bring along the .NET Core SDK along with the Resolvers that @rainersigwald mentioned above. So, you will be able to invoke msbuild on your solution even if it contains .NET projects. The only requirement is that the .NET Core SDK be on your path, which the build SKU installer will do for you. The only missing piece at this point is having NuGet in the build SKU, which is being tracked by an issue that @rainersigwald referenced above.

[rainersigwald]

Current NuGet tracking issue is https://github.com/NuGet/Home/issues/3660.

[se7vanj]

On a similar problem with my machine, I had to reset the below file which was accidentally modified when I was trying to make my assemblies to be on net45 and core api targetting to net45. After that it was not building my solution and started to throw different errors, even after I reverted back everything to target with .net core. Tried deleting VS related cache/settings folders of my local user login, no result, then I was about to uninstall VS2017, before that found the below file had a modified timestamp and somehow got its original content. Now its fine to build and run my original solution which is targetting to .net core.

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets

[OskarKlintrot]

Milestone MSBuild 15.3 is closed since 3 weeks ago and every issue but this one is resolved. Any ideas for when this issue will be resolved?

[dasMulli]

if I understand it correctly, NuGet 4.4 will be part of the VS 2017 15.4 build tools (https://github.com/NuGet/NuGet.Client/pull/1626) and SDK resolution already works when the .NET Core CLI ("SDK") is installed.

[matkoch]

@matkoch

[UncleFirefox]

Hey guys, been following this issue for a while, after installing the 15.4.1 it seems the issues are still there... Aka, no target restore nor sdk support for the new csproj format... Will we get a fix anytime soon?

[joakimskoog]

Any news on this?

[livarcocc]

I believe this is in now in VS 15.4.

@AndyGerlicher can we close this now?

[dasMulli]

@joakimskoog as @UncleFirefox wrote at https://github.com/NuGet/NuGet.Client/pull/1626#issuecomment-339245174 check if the workloads you selected (cross-platform .net) also pull in the NuGet targets: