Retarget DOTNETHOME when installing x64 on ARM64 #11843
Conversation
DOTNETHOME may not always be set, be sure to install the tag to a predictable location.
We changed the bundle to not pass in default values for DOTNETHOME because it cannot calculate them in all cases: there is no way to conditionally set a path which does not exist. As a result, the MSI needs to calculate them so that it can write the appropriate defaults.
|
Ok I've added searches to the CLISDK MSI to set the DOTNET_* values even when the bundle doesn't set them. This should be good to go. |
|
|
||
| <!-- Permit same path on non-ARM64 machines since past SDKs always wrote this value --> | ||
| <bal:Condition Message="The installation path for ARM64 SDK installations: "[DOTNETHOME_ARM64]" cannot be the same as for x64 SDK installations: "[DOTNETHOME_X64]""> | ||
| WixBundleInstalled OR (NOT DOTNETHOME_ARM64 ~= DOTNETHOME_X64) OR (NOT NativeProcessorArchitecture="ARM64") OR DOTNETHOMESIMILARITYCHECKOVERRIDE |
There was a problem hiding this comment.
Note that I special cased this condition because all the existing SDKs already write keys for x64 and ARM64 on Windows. The value for ARM64 on an x64 machine is innocuous, since it exists and won't cause any bad behavior, unless windows finds a way to let ARM64 code run on x64 😆
There is a more annoying pathological bug as a result of this, but I'd like to peel that off. See #11999
|
Pinging again. Folks I need feedback on this so that we can backport it to 6.0. |
| </Property> | ||
|
|
||
| <!-- Set the DOTNETHOME property if not passed in and we found a path --> | ||
| <SetProperty Id="DOTNETHOME_X86" Value="[DOTNETHOME_X86_SEARCH]" Before="CostFinalize"> |
There was a problem hiding this comment.
I think I got this. The only time we'd be in trouble is a clean install, where the bundle fails to pass DOTNETHOME_xxx and the search won't find anything because we've never been installed and that would technically point to an authoring error. I need to check how the SDK is authored into VS because there VS takes the place of the bundle to pass in DOTNET_HOME to the MSI
There was a problem hiding this comment.
We shouldn't have to pass in defaults. A clean install won't detect it as it runs searches up front in the bundle. We can run similar searches here so that we detect it after the host was installed. The bundle's searches miss this because they run before the host is installed.
In general we have to be very careful when using public properties to control installed content: think through all scenarios of install/repair/patch(if supported)/uninstall/upgrade to make sure property values are correct. Never count on the MSI being "called correctly" to get that stuff right.
I need to check how the SDK is authored into VS because there VS takes the place of the bundle to pass in DOTNET_HOME to the MSI
We should remove those. The meaning of DOTNETHOME public properties is "final install location of dotnet root directory". This assumption is made in SDK bundle authoring and one that is a public contract with users that we cannot break. We're changing the default for x64. If someone is specifying that (including VS bundle) by duplicating the defaults it needs to change to reflect the new default.
|
/backport to release/6.0.1xx-rc2 |
Retarget DOTNETHOME when installing x64 on ARM64
|
@joeloff @marcpopMSFT -- anything that needs to happen to get this change into the 6.0 branch too? I see it seems to be missing there |
|
If it's in RC2 then that will get flowed during a mopup merge back into 6.0.1xx |
…ation After dotnet#11843, post build signing started failing, failing to find one of the input wixobj files. The wixobj was not included in the wixpack. This is because the installer repo uses custom scripts to generate MSIs, rather than the arcade tasks (which would handle adding this transparently), so the input files need to be added explicitly.
…ation (#12100) After #11843, post build signing started failing, failing to find one of the input wixobj files. The wixobj was not included in the wixpack. This is because the installer repo uses custom scripts to generate MSIs, rather than the arcade tasks (which would handle adding this transparently), so the input files need to be added explicitly.
Redirects installer MSIs to x64 subfolder.