-
Notifications
You must be signed in to change notification settings - Fork 83
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
Find x64 MSBuild from Locator #135
Conversation
src/MSBuildLocator/MSBuildLocator.cs
Outdated
} | ||
else | ||
{ | ||
string msbuildDll = Path.Combine(path, "MSBuild.dll"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do this for the DLL? I thought the problem was only for .NET Framework x64 applications?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't 100% sure of this, but if you have a .NET Framework app and use RegisterMSBuildPath(<.NET Core MSBuild path>), I think you would have trouble if you tried to use anything that differs between Core and Framework, but you could maybe stick to the overlap and having a working app. Should that be something to care about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that should fail pretty quickly and if it doesn't today it might tomorrow, as .NET diverges from .NET Framework 4.8. No need to attempt to support it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is why we should add tests and verify these configurations, perhaps with Docker.
Actually checking for NET46 because that's the only Framework version in the TargetFrameworks, though it would be good to change that eventually.
The change in #135 was supposed to be made unnecessary by dotnet/msbuild#6890, but apparently my setup is the only one that has dotnet.exe under both the dotnet folder and the sdks folder, so it didn't work. @xen2 fixed the problem in dotnet/msbuild#7013, but that won't get in 'til 17.1, so we need to prolong the version check here. Co-authored-by: xen2 <[email protected]>
Fixes dotnet/msbuild#6681 for pre-17.0 MSBuild.
MSBuild can be loaded from the x86 or x64 folder. Before 17.0, it looked next to the executing assembly in some cases and constructed a path that assumed x86 in others. This overrides the latter assumption to let it find the right MSBuild.