Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking: .NET Core Sdk in Build Tools Installer #1697

Closed
debanne opened this issue Feb 14, 2017 · 38 comments
Closed

Tracking: .NET Core Sdk in Build Tools Installer #1697

debanne opened this issue Feb 14, 2017 · 38 comments
Labels
Milestone

Comments

@debanne
Copy link

debanne commented Feb 14, 2017

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
Copy link
Member

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
Copy link
Member

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 rainersigwald changed the title Guidance on Visual Studio Build Tools 2017 RC and the Sdks Tracking: .NET Core Sdk in Build Tools Installer Mar 8, 2017
@rainersigwald
Copy link
Member

Related: NuGet/Home#3660 (getting NuGet restore into the Build Tools installer).

@Spongman
Copy link

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

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

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

@mariusGundersen
Copy link

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

evil-shrike commented Mar 21, 2017

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

and where is it?

@mariusGundersen
Copy link

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
Copy link
Contributor

dasMulli commented Mar 23, 2017

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

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

ghost commented Apr 17, 2017

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

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

ghost commented Apr 17, 2017

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

@ntregillus
Copy link

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
Copy link
Contributor

tbolon commented Apr 28, 2017

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

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 rainersigwald added this to the MSBuild 15.3 milestone Apr 28, 2017
@rainersigwald
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

dasMulli commented Apr 28, 2017

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
Copy link
Member

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

@Aleksanderis
Copy link

Aleksanderis commented May 4, 2017

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

matthid added a commit to fsprojects/FAKE that referenced this issue May 26, 2017
@avikenjale
Copy link

@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
Copy link

@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
Copy link

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

fenneh commented Jun 15, 2017

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

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

jetersen commented Jun 16, 2017

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

@livarcocc
Copy link
Contributor

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
Copy link
Member

Current NuGet tracking issue is NuGet/Home#3660.

@se7vanj
Copy link

se7vanj commented Aug 13, 2017

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

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
Copy link
Contributor

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

@matkoch
Copy link

matkoch commented Sep 23, 2017

@matkoch

@UncleFirefox
Copy link

UncleFirefox commented Oct 24, 2017

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

Any news on this?

@livarcocc
Copy link
Contributor

livarcocc commented Nov 14, 2017

I believe this is in now in VS 15.4.

@AndyGerlicher can we close this now?

@dasMulli
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests