-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Document how to resolve MSBuild location #1377
Comments
Thanks for creating this issue, @devlead. Documentation is currently in the works. Feel free to ask questions regarding the VS 2017 RC release here. |
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. |
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. |
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. |
What I strongly dislike is this fragility: 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. |
Bootstrapping from NuGet also makes allot of sense for build agent scenarios. |
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" <notifications@github.com> 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
<#1377 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADgXKp0HOOGzl4wM7glePdiQ2nuRqn3ks5rJGINgaJpZM4K5GDG>
.
|
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: 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();
} |
One thing I've noticed is that there is a difference between which MSBuild version is used and the things like Either that or ship all of the platform tasks/targets as NuGet's (even if they will only run on Windows). |
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 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. |
@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 :/ |
@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. |
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 @Sarabeth-Jaffe-Microsoft we need to make sure this makes it into formal documentation. |
MicrosoftDocs/visualstudio-docs#761 has documentation on how to use Microsoft.Build.Locator to load the copy of MSBuild from the user's installed Visual Studio. |
Following up twitter discussion with @terrajobst and @damianh and creating this issue to track progress of the docs being created.
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.
The text was updated successfully, but these errors were encountered: