msbuild
msbuild copied to clipboard
dotnet
Add Microsoft.Build.dll to the arm64 directory
Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1526195/
Context
NuGet Pack expects Microsoft.Build.dll to exist in the same directory as the running exe. On ARM64 machines, nuget pack results in M.Build.dll not being discovered under /arm64/
Changes Made
Testing
Notes
This is a "just in case" PR to have around as I perform investigation to see if NuGet should be doing something differently.
With reference to this https://github.com/dotnet/msbuild/pull/7736#issuecomment-1164901473
Would MSBuild and its dependents break (with appropriate fixes and redirects of course) if we point all to the current layout instead of amd64, arm64 and friends? With MSBuild being Any CPU as you said, does it even matter to have architecture subdirectories?
If this is possible, we could save some disk space!!
Would MSBuild and its dependents break (with appropriate fixes and redirects of course) if we point all to the current layout instead of
amd64,arm64and friends? With MSBuild being Any CPU as you said, does it even matter to have architecture subdirectories?If this is possible, we could save some disk space!!
We must have the architecture subdirectories for executables, because that's the only way to flip the Windows architecture bit for msbuild.exe and msbuildtaskhost.exe.
For the other assemblies, MSBuild.exe and devenv.exe should only ever use the copies in bin, but we've observed breaks in first-party and third-party applications that manually load the copies from bin\amd64, so we are shipping them for compat. For arm64, we're hoping to never ship them in the first place so users are forced to use the ones from bin and we can reduce install size. But if there are uses that can't accommodate that, we can ship the assemblies again--like in this PR.
@BenVillalobos don't forget to close or undraft this, as necessary :)
I can't install the package that would let me confirm that we need this, and the issue hasn't gotten any other hits. Closing.
If it gets more hits I'll dig further in.
See my latest comment in https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1526195?src=WorkItemMention&src-action=artifact_link.
TL;DR: NuGet manually checks for Microsoft.Build.dll wherever MSBuild happens to be found on the PATH. Given we should support existing scenarios, and NuGet is a pretty big internal customer of ours, we shouldn't expect them to manually account for an 'msbuildism' like this. IMO we merge this PR so other customers can expect things to behave the same, even on new architectures.
@rainersigwald This is in a super specific scenario in classic csproj scenarios running nuget.exe directly. It doesn't repro running dotnet pack so it seems like a "low traffic" issue. Also, running the same repro on the sln instead of the project outputs the desired behavior. I'm leaning towards no. cc @marcpopMSFT , who seems to agree
@aortiz-msft may also have a "should this fix to nuget.exe pack be pushed to 17.4?". If you don't think it's super important we'll fix for 17.5.