Msbuild: Document how to resolve MSBuild location

[devlead]

Following up twitter discussion with @terrajobst and @damianh and creating this issue to track progress of the docs being created.

@terrajobst wrote:
I've pinged the MSBuild folks. They are working on a doc that will be public soon.

@devlead wrote:
@terrajobst @randompunter that's great news! Thanks for getting back to us, is there an GH issue one can subscribe to?

@terrajobst wrote:
@devlead @randompunter no, but feel free to create one. I'll let them know that they should respond to it. https://GitHub.com/Microsoft/MSBuild/issues/new

Full thread here

Not certain on what's exactly being documented, but I guess if we find anything lacking we'll post that feedback here.

[Sarabeth-Jaffe-Microsoft]

Thanks for creating this issue, @devlead. Documentation is currently in the works. Feel free to ask questions regarding the VS 2017 RC release here.

[jnm2]

If I have an open source project with a build script, my build script should not have to be responsible to decide what edition of Visual Studio is preferred when locating msbuild if there are multiple installed (Community vs Professional trial).

Ideally there should be a way to locate the default msbuild path for a given tool version.

[devlead]

Well the author of a build script should be able to pin which version of the tooling to use, for that to work we either need reliable documented way to find and execute that version. Or be able to fetch that tool via i.e. something like NuGet or Chocolatey.

[jnm2]

Fetching msbuild via a NuGet feed would be fantastic. I wouldn't have to worry what was installed and I'd have fine-grained control over minimum and maximum versions.

[jnm2]

What I strongly dislike is this fragility:

c# var msbuildPath = Path.Combine( Directory.EnumerateDirectories(Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86), "Microsoft Visual Studio", "2017")).First(), "MSBuild", "15.0", "Bin", "msbuild.exe");

Not only do I want to use msbuild if VS is _not_ installed, but I also don't want to have to search a cross product of VS versions, VS editions, and msbuild versions.

[devlead]

Bootstrapping from NuGet also makes allot of sense for build agent scenarios.
Still waiting see what the end result of project.json->csproj will be, but if the tooling is a first class citizen then all non standard msbuild targets should be able to be fetched thru NuGet too.
Which feels almost utopian when I think of it 😄

[damianh]

No build script should ever depend on Visual Studio.

In fact all build tools should be xcopy deployable (i.e. msbuild nuget
package)

On 17 Dec 2016 11:28 p.m., "Joseph Musser" [e-mail] wrote:

If I have an open source project with a build script, my build script
should not have to be responsible to decide what edition of Visual Studio
is preferred when locating msbuild if there are multiple.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/msbuild/issues/1377#issuecomment-267791220,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgXKp0HOOGzl4wM7glePdiQ2nuRqn3ks5rJGINgaJpZM4K5GDG
.

[jnm2]

Is it safe to start a request specifically for a NuGet tools package?

Otherwise we're stuck in a world I really don't want to live in:

```c#
string GetMSBuildPath(Version minVersion, Version maxVersion)
{
if (minVersion < new Version(15, 0))
throw new NotImplementedException("Logic for pre-15.0 msbuild location");

return (
    from vsVersionDir in Directory.EnumerateDirectories(Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86), "Microsoft Visual Studio"))
    let vsVersion = int.TryParse(Path.GetFileName(vsVersionDir), out int version) ? version : (int?)null
    where vsVersion != null
    orderby vsVersion descending
    from vsEditionDir in Directory.EnumerateDirectories(vsVersionDir)
    // orderby ?
    from msbuildVersionDir in Directory.EnumerateDirectories(Path.Combine(vsEditionDir, "MSBuild"))
    let msbuildVersion = Version.TryParse(Path.GetFileName(msbuildVersionDir), out Version version) ? version : null
    where msbuildVersion != null && (minVersion == null || minVersion <= msbuildVersion) && (maxVersion == null || msbuildVersion <= maxVersion)
    orderby msbuildVersion descending
    let msbuildPath = Path.Combine(msbuildVersionDir, "Bin", "msbuild.exe")
    where File.Exists(msbuildPath)
    select msbuildPath).FirstOrDefault();

}
```

[clairernovotny]

One thing I've noticed is that there is a difference between which MSBuild version is used and the things like MSBuildExtensions directory. If you're just doing vanilla builds, this doesn't matter. But if you're using multi-targeting to include the "native platform" targets like the WindowsXaml one, where it needs to be the version of MSBuild set by "VCVars" so that it picks up all those paths correctly.

Either that or ship all of the platform tasks/targets as NuGet's (even if they will only run on Windows).

[clairernovotny]

Bottom line -- if you want to use the native platform targets, it will require VS on the machine and knowing to use the version of MSBuild from that particular instance. 

[devlead]

Bottom line -- if you want to use the native platform targets, it will require VS on the machine and knowing to use the version of MSBuild from that particular instance. 

Even if this is the case today I don't think it should be tomorrow, SDKs shouldn't be tied to specific IDE version just to be able to build it. Anyone that's done CI with Silverlight, older versions of MVC, SQL Assemblies, etc. etc. can attest how horrible that experience can be. And hopefully we're better than that 2016.
Having to install & maintain all ever created versions of Visual Studio just doesn't fly. But is a must as they drop support for as many project types as they add each version.

Having the possibility to fetch and use a specific version tooling was one of the most appealing features of .NET Core, one would hope that's a behavior getting more adopted by more SDKs and tools going forward.

[clairernovotny]

@devlead Oh, I agree. I'd love to have all of the platform-specific targets/tasks be available via NuGet. Just saying that they're not today and that the location of msbuild matters :/

[devlead]

@onovotny that's why I'm looking forward to at least having good and clear documentation on how to find specific installed versions of MSBuild.

[rainersigwald]

The VS setup team has posted a PowerShell helper to find Visual Studio installs: https://github.com/Microsoft/vssetup.powershell/wiki.

MSBuild should be present in every install of VS2017 (that I know of). But the tasks, targets, and other extensions required to build a specific project may not be available in every instance. To be fully robust, you probably want to query for a specific workload/component corresponding to your project type (for example, you might know that you need Microsoft.VisualStudio.WCF).

@Sarabeth-Jaffe-Microsoft we need to make sure this makes it into formal documentation.

[rainersigwald]

https://github.com/MicrosoftDocs/visualstudio-docs/pull/761 has documentation on how to use Microsoft.Build.Locator to load the copy of MSBuild from the user's installed Visual Studio.