Identify 64-bit MSBuildToolsPath from 64-bit API consumer#6683
Conversation
|
Hmm. The failure in |
Maybe a new PR that removes the concept from MSBuild altogether? |
rainersigwald
force-pushed
the
64-bit-environment
branch
from
190a063 to
9fed5b2
Compare
|
In the latest version of the PR, how are you making sure that the |
Your tired eyes are better than my midafternoon eyes, it seems. Reverting that change. |
Also eliminates the unspecified need to only pass in MSBuild.exe as the assembly.
Fixes dotnet#6681 by finding the VS root from the current assembly and then reconstructing the path to the appropriate MSBuild.exe based on that + the current process's bitness, ensuring that API consumers and MSBuild.exe/devenv.exe see the same MSBuildToolsPath.
The new process to find MSBuild cares only about the real runtime architecture of the running process, not the path passed in, so these tests no longer successfully simulate the 64-bit case. Dropping them instead.
I can't think of a reason to want to attempt to load (part of) an MSBuild 15.0 toolset with MSBuild 17.0+.
rainersigwald
force-pushed
the
64-bit-environment
branch
from
9fed5b2 to
255b4d0
Compare
ladipro
added
the
merge-when-branch-open
A 64-bit application is now (after dotnet#6683) getting a good VS root path, but may still use toolsets from the wrong directory, because if it loaded (AnyCPU) assemblies from the 'x86' location it wouldn't pass a path containing �md64 to the BuildEnvironment constructor, so the logic there wouldn't find the right MSBuildToolsDirectory and config file. Fix this in the lowest-impact way by rederiving the path to the 'correct' MSBuild.exe from the VS root and passing that to the BuildEnvironment constructor.
A 64-bit application is now (after #6683) getting a good VS root path, but may still use toolsets from the wrong directory, because if it loaded (AnyCPU) assemblies from the 'x86' location it wouldn't pass a path containing �md64 to the BuildEnvironment constructor, so the logic there wouldn't find the right MSBuildToolsDirectory and config file. Fix this in the lowest-impact way by rederiving the path to the 'correct' MSBuild.exe from the VS root and passing that to the BuildEnvironment constructor.
4 participants
Fixes #6681.
Context
The change to make Visual Studio 64-bit means that projects loaded in Visual Studio get the 64-bit MSBuild, and other tools are more likely to be loading our API in a 64-bit process as well. That found this difference between the way projects are evaluated in
devenv.exeand invcxprojReader.exe.Changes Made
Find the VS root from the current assembly and then reconstruct the path to the appropriate MSBuild.exe based on that + the current process's bitness, ensuring that API consumers and MSBuild.exe/devenv.exe see the same MSBuildToolsPath.
Testing
Manual overlay with a trivial API consumer.