Install xcopy MSBuild

[jaredpar]

Is there a way to install MSBuild 15.0 in an xcopy fashion?

Given the changes to Visual Studio 2017 it seems that this should be possible. This is the only tool remaining in the Roslyn build process which isn't xcopy deployable. I'm pretty sure that with an xcopy MSBuild I could clone, build and run tests in Roslyn on a fresh Windows 10 machine.

[jeffkl]

@jaredpar the Microsoft.Build.Runtime should contain everything you need for MSBuild. If you want to evaluate or build projects, you'll need a few more packages like Microsoft.Net.Compilers.netcore and Microsoft.CodeAnalysis.Build.Tasks (which now have to be placed in a Roslyn subfolder or you have to set RoslyTargetsPath explicitly. This will is enough to build a basic .csproj or .vbproj. And then you'll need additional packages for other SDKs unless the project itself contains enough package references to get the build dependencies.

This is my test application I've been using to show things working in a stand-alone fashion: https://github.com/jeffkl/MSBuild-NetCore/tree/master/src/ConsoleApplication

[rainersigwald]

Yes, this should be possible now, but there's no easy way to do it at the moment. The main issue is that not all of the props and targets that are required for a "reasonable" MSBuild are present in this repo--Roslyn being a notable absence. Everything gets assembled by the VSIXes in VS or by the CLI repo for .NET Core.

For you in Roslyn, it's probably ok to not have Roslyn targets redistributed, depending on how your bootstrap is set up. You might be able to just unzip the Microsoft.Build.Runtime package and run from there (with explicit references to your LKG compiler).

[Crossed with @jeffkl so may be repetitive]

[jaredpar]

Does the MS.Build.Runtime package contain everything needed to enable NuGet restore and reference resolve issues? Also does it have the desktop reference assemblies?

[jeffkl]

No NuGet restore is not part of the "core" MSBuild logic at the moment. This is handled by Visual Studio or the dotnet CLI. We're working on a feature where MSBuild will be able to restore SDK packages which could then restore NuGet package references.

Another possibility could be to zip up the MSBuild folder from a VS install but I haven't tried it.

[jeffkl]

Also, would it work if you just installed the MSBuild tools part of Visual Studio on the machine? This part of the install should be very minimal and fast...

[jaredpar]

No NuGet restore is not part of the "core" MSBuild logic at the moment.

That's unfortunate. I'm really interested in driving down the pre-requisites needed to build DotNet projects. Today it far too often comes down to "install Visual Studio" which is a pretty big burden. I think it would be great if we can get it to a simple "grab this toolset" and go.

It seems like there are at a minimum the following required components:

1. NuGet.exe: available today as a direct download today. On Windows only though.
2. NuGet tasks for resolving references during build
3. MSBuild core components
4. Roslyn compilers

I feel like 2 is the big item we are missing. Everything else can be cobbled together. I'm not even sure where this code lives.

Another possibility could be to zip up the MSBuild folder from a VS install but I haven't tried it.

I agree that should work. But it's not ... official. It's a bit hacky.

Also, would it work if you just installed the MSBuild tools part of Visual Studio on the machine?

How would one go about doing that?

[jeffkl]

@jaredpar I agree, that's why I came up with http://commonbuildtoolset.github.io/ which is a hook into MSBuild which allows for bootstrapping build dependencies at build time. I haven't had a chance to make it work with .NET Core yet though but it is why I joined the MSBuild team.

I can say that the near term goal is to accomplish exactly what you want which is that MSBuild acquires all build dependencies for you so you can just "clone and go". The new SDK stuff I spoke about is slated for update 1 and I've already started working on it based on this design: #1493. It will work from the command-line, Visual Studio, Windows, Linux, etc. The lowest common denominator is MSBuild so that's all you'll need as a prerequisite.

The DotNet CLI might also be a good option but I'm not sure if it can build desktop framework apps yet. It is xcopy deployable and comes with MSBuild, Roslyn, and NuGet.

To install just the build tools, you can download this: https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017-rc

And then do an unattended installation on build servers by doing this: https://docs.microsoft.com/en-us/visualstudio/install/visual-studio-administrator-guide

[cdmihai]

@jaredpar Isn't the CLI good enough? It's pretty much xcopy-able and puts together nuget, msbuild, and roslyn. As @jeffkl said, after this VS release we'll be working on teaching msbuild how to acquire dependencies: #1493. The end goal is to clone and build with only msbuild on the machine.

[jaredpar]

Isn't the CLI good enough? It's pretty much xcopy-able and puts together nuget, msbuild, and roslyn

The phrase "pretty much" is suspicious. Is there a supported xcopy way to grab it? If so then yeah it might be enough.

[rainersigwald]

You'd need CLI + full-framework MSBuild in a zip (or NuGet or whatever). CLI could do NuGet operations but you'd want to use full framework MSBuild (which doesn't come with CLI at the moment) to make sure the build matched the installed version.

CLI does come in an xcopy mode (not sure the official "supportedness"). For example https://dotnetcli.blob.core.windows.net/dotnet/Sdk/rel-1.0.0/dotnet-dev-win-x64.latest.zip

[mfilippov]

I also would like to have the option of a msbuild xcopy installation for a Full and CLI version.

[jaredpar]

As a counter example consider the instructions for acquiring Maven. They are as simple as it gets. In summary: download and unzip. Imagine if it were that easy to get a functional MSBuild environment going.

[rainersigwald]

@jaredpar I don't see anyone disagreeing with that goal. We're just not there yet.

[jaredpar]

@rainersigwald gotcha.

Do you have any thoughts on what would be the minimum collection of items in that package? Been pondering this and it seems it would include:

• Core msbuild
• NuGet.exe
• MSBuild Extensions
  • Roslyn
  • NuGet asset resolution task
  • SDK bits

In looking around .Net that seems to be the core set of tools that necessary for building most repos. Possible I'm missing other core sccenarios though.

[dsplaisted]

@jaredpar If you want the .NET Core version of MSBuild, then you can pretty much get this with the .NET CLI. The "Binaries" download links are to .zip files with xcopy-able contents. There are also scripts in the CLI repo that you can use to download and extract everything.

I think the only thing from your list that isn't included is NuGet.exe, and that's because NuGet.exe is for the full .NET Framework and in the CLI, and the NuGet functionality is provided via other means (targets in MSBuild, dotnet restore, etc.).

[jaredpar]

@dsplaisted the last time we used dotnet restore it couldn't handle our NuGet packages (csproj with project.json files). That's a bit of a blocker.

[jaredpar]

@dsplaisted addtionally the CLI only supports CoreClr compilers. That's a break in some cases as we need full framework to run some of the analyzers.

[jaredpar]

Been looking into this again. I'm still at a loss as to where the NuGet Asset resolution deliverables are coming from. Can someone get me pointed in the right direction? That seems to be the one big piece that we don't have info one.

@dsplaisted

Been looking into this more and CLI does not appear to be an option here for dotnet/roslyn in the near term. Even though it is driving MSBuild it is doing so using CoreCLR. Hence it rules out any build tasks which are tied to desktop.

Roslyn uses a number of those, most notable the VS SDK build tools but including several others. There is no real gain to be had for these tasks to move to CoreCLR as they target desktop only scenarios. Hence Roslyn for the forseable future is going to need a full MSBuild to build our Windows assets.