Msbuild: Deployment of targets with MSBuild

[rainersigwald]

In dev14, MSBuild was machine-global and had a defined machine-global place for extensions (targets and task assemblies). This allowed MSBuild to deliver the core targets and tasks (and the engine), and other SDKs to augment its surface area by copying files to a known location.

In the future, MSBuild won't require installation and you might have many copies of it on your machine. But projects will continue to refer to properties like $(MSBuildToolsPath) and $(MSBuildExtensionsPath), which will be resolved relative to the currently-in-use copy of MSBuild. Those projects will fail to load or build if the targets files they need are missing.

To some degree, this will be alleviated by referring to SDKs via NuGet package. But MSBuild must have enough targets to know how to handle NuGet references.

Currently, MSBuild handles this for our bootstrapped build by restoring several NuGet packages that contain MSBuild logic and copying it to the right places in our output. But that kind of manual reconstruction is a high bar to clear for an MSBuild consumer--it'd be vastly better if you could just depend on a package that delivered everything you needed.

Questions:

• Ownership of the metapackage that contains the engine + specific targets
• Combinations (you should be able to say "get me a copy of MSBuild that can build C# _and_ F# projects")
• Can we somehow point to a VS installation, where all of these things will be solved by the VS packaging system?

[weshaggard]

Can we somehow point to a VS installation, where all of these things will be solved by the VS packaging system?

That doesn't help with x-plat we would need to have a story that isn't that for them and I think we should try to have the same story if possible.

[xied75]

Definitely DO NOT consider VS is around. Think about Windows Container for build bot purpose.

Also I have a related question, not sure to raise a separate issue though: does the current release of Opened MSBuild include all those targets? If not, how does one grab those targets, e.g. for people to build for IIS Express, where to grab the WebApplications target? ( I see there is one on NuGet: https://www.nuget.org/packages/MSBuild.Microsoft.VisualStudio.Web.targets/, is this allowed/encouraged? ) Another would be the current version Portable targets, which does not even have a downloadable link on MSDN ( only on VS ISO ).

[rainersigwald]

@xied75 As you noticed, right now there's no uniform place to get targets. That should improve in the Dev15 timeframe, but it's important to note that Microsoft is not committing to packaging targets for everything (as much as I might personally love that). Building some project types will probably still require installation of Visual Studio with the appropriate install options checked.

As @weshaggard points out, that cannot be the case for the sorts of things that we support building cross-platform, like .NET Core apps and libraries. Targets from that should come from official public packages and we should provide a nice all-up way to get a build environment that includes MSBuild + targets. Ideally more and more things move to this model over time.

[xied75]

@rainersigwald Thanks for the reply. Cross platform is important but I'm more concerned on Container, to insist to install VS inside container only for 2 or 3 tiny target files sounds bizarre, as of today, we can install multiple versions of NETFX with msi, install msbuild tooling with msi, but not some of the targets, and the whole build chain collapse. Even the Windows team finally understood what's facing them and come out the Nano Server, I can't imaging the VS team will go backwards and insist for us to waste 8GB disk space while the Nano is only couple of hundreds MB.

Besides, the container does not offer us Visual, so what to Visual for?

Can't we get those Targets to have an independent life? ( I thought this is what you mean in the thread ), can this work be Open Source? So that we can come up a plan and make it work.

p.s. Better to ask explicitly: are those Targets covered by MIT license as msbuild?

[cdmihai]

My assumption is that dotnet CLI would ship with a variant of deployed MSBuild, so users can use that on x-plat. Out of the box it is C#. In the past it had certain extensions to bring down F# and VB support.

[rainersigwald]

@xied75 An install-free experience is a worthy goal, and one that I support. But as always, the default future is "status quo", so installation requirements will continue to exist until they're changed. That is not a primary focus of current work. There's work to make Visual Studio installation faster and smaller, and work around cross-platform .NET development, which is package-based.

This repo provides the MSBuild core engine and tasks, and the most basic of targets. Files in this repo are governed by this repo's license.

Layered on top of MSBuild are various SDKs that have different levels of installation and licensing requirements. Some are open source, some remain proprietary parts of Visual Studio, and some are entirely third-party. If you'd like to influence the direction of the Microsoft SDKs, your best bet is probably the usual support channels and UserVoice.

[jcansdale]

There's work to make Visual Studio installation faster and smaller, and work around _cross-platform_ .NET development, which is package-based.

Ah, so that is why the new installer is based on Node.js? :)

[mletterle]

I feel like perhaps this issue is more what my comment in #1461 was about, so bumping this. Feels like something that should be resolved.

Is there any solution going forward for things that are not SDKs and/or Nuget Packages?

[rainersigwald]

For VS 2017/MSBuild 15.1:

• This repo contains core targets.
• This repo's targets are redistributed in the Runtime package: #1039.
• When invoked, MSBuild finds targets using the mechanisms described in #1461.
• https://github.com/dotnet/sdk/ contains the .NET Core SDK which is cross-platform.
• Visual Studio and the dotnet CLI assemble the SDK and NuGet (and things like the compilers) into a known folder structure.
• VS also (conditional on what checkboxes you tick in the installer) installs other targets.
• Other means can continue to be used to install targets to machine-global locations.

In the future, the plan is for the experience to be smoother with Sdk acquisition. That should mean just having the MSBuild core assemblies + an SDK resolver will be sufficient to bootstrap and build projects.