-
Notifications
You must be signed in to change notification settings - Fork 341
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
Adding detection and retargeting of DOTNETHOME #7785
Conversation
When x64 is installed on non-x64 machine, place in an x64 subdirectory.
Runtime side of changes: dotnet/runtime#58059 |
src/Microsoft.DotNet.Build.Tasks.Workloads/src/GenerateManifestMsi.cs
Outdated
Show resolved
Hide resolved
1589f3c
to
f927eb5
Compare
f927eb5
to
ffecbc5
Compare
Don't need to use a registry search since environment of the MSIServer process can be read (TBD pending reccomendation from MSI team). Also make property work for any architecture, in case we wish to use it more generically (EG: to condition PATH entry in host installer).
I'd like to start merging these pull-requests into MAIN and working up the stack. We'll validate the scenario using the installers in main, then port to 6.0. |
src/Microsoft.DotNet.Build.Tasks.Workloads/src/MsiTemplate/Registry.wxs
Outdated
Show resolved
Hide resolved
<!-- Identify when installing in emulation as when PROCESSOR_ARCHITECTURE does not match the installer architecture | ||
https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details --> | ||
<SetProperty Action="Set_INSTALLING_IN_EMULATION" Id="INSTALLING_IN_EMULATION" Value="true" Before="CostFinalize"> | ||
NOT %PROCESSOR_ARCHITECTURE="$(var.InstallerArchitecture)" |
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.
Once we have wixtoolset/issues#6556 this goes away.
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.
We'll need to port this into release/6.0 as well I think since Arcade snapped and main now targets 7.0
FYI @pjcollins this will impact maui workload pack generation
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.
We'll need to port this into release/6.0
Right, that's the plan here: #7785 (comment)
src/Microsoft.DotNet.Build.Tasks.Installers/build/wix/product/product.wxs
Outdated
Show resolved
Hide resolved
src/Microsoft.DotNet.Build.Tasks.Workloads/src/Microsoft.DotNet.Build.Tasks.Workloads.csproj
Show resolved
Hide resolved
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.
Looks good, thanks Eric.
* Adding detection and retargeting of DOTNETHOME When x64 is installed on non-x64 machine, place in an x64 subdirectory. * Remove test value of dotnet folder * Fix ProgramFilesFolder preprocessor variable usage * Refactor Set_DOTNETHOME_x64 into a single shared source file * Add CA ID for INSTALLING_IN_EMULATION. * Define Platform consistently * Move workload registration to platform specific * Refactor INSTALLING_IN_EMULATION property Don't need to use a registry search since environment of the MSIServer process can be read (TBD pending reccomendation from MSI team). Also make property work for any architecture, in case we wish to use it more generically (EG: to condition PATH entry in host installer). * Make platform comparison case insensitive * Respond to feedback
When x64 is installed on non-x64 machine, place in an x64 subdirectory.
This is still a WIP. We could share this with both Installers and workloads SDK, perhaps with just a common source file. I'd also like to better understand once putting together some consumption PRs upstack.