Working ANCM arm64 installers

[HaoK]

Part of #39281

First checkpoint: working arm64 installers that currently just put things down exactly where the x64 installer does, just adds arm64 names/component ids and installer logic. I verified that the artifacts do install and drop ANCM on an arm64 machine:

Next PR will start making things light up (and work).

[HaoK]

@aspnet-build am I doing bad things to concurrency by adding more arm64 build steps here for the installers?

First time I've seen this error in a long time, on the ubuntu test job:

.dotnet/sdk/7.0.100-preview.2.22114.1/Microsoft.Common.CurrentVersion.targets(4808,5): error MSB3026: (NETCORE_ENGINEERING_TELEMETRY=Build) Could not copy "/mnt/vss/_work/1/s/artifacts/bin/Microsoft.AspNetCore.Http.Extensions/Release/net7.0/Microsoft.AspNetCore.Http.Extensions.dll" to "/mnt/vss/_work/1/s/artifacts/bin/SystemdTestApp/Release/net7.0/Microsoft.AspNetCore.Http.Extensions.dll". Beginning retry 1 in 1000ms. The process cannot access the file '/mnt/vss/_work/1/s/artifacts/bin/Microsoft.AspNetCore.Http.Extensions/Release/net7.0/Microsoft.AspNetCore.Http.Extensions.dll' because it is being used by another process. 

[HaoK]

@wtgodbe looks like I'm getting an error about 64bit using a 32bit in Product.wxs not sure why this one is complaining...

Looks like you added these recently for microsoft update, any ideas what I need to do to make this happy? SO claims this might be safe to ignore since we are building cross bitness installers with these wxs files

##[error]src\Installers\Windows\HostOptions\Product.wxs(53,0): error LGHT0204: (NETCORE_ENGINEERING_TELEMETRY=Build) ICE80: This 64BitComponent OPT uses 32BitDirectory MM

https://github.com/dotnet/aspnetcore/blob/haok/arm64/src/Installers/Windows/HostOptions/Product.wxs#L53

[wtgodbe]

Do you have the error message? I think it should be safe to ignore too, but @joeloff may know for sure

[HaoK]

Yeah its just

D:\a\_work\1\s\src\Installers\Windows\HostOptions\Product.wxs(53): error LGHT0204: ICE80: This 64BitComponent OPT uses 32BitDirectory MM [D:\a\_work\1\s\src\Installers\Windows\HostOptions\HostOptions.wixproj]
##[error]src\Installers\Windows\HostOptions\Product.wxs(53,0): error LGHT0204: (NETCORE_ENGINEERING_TELEMETRY=Build) ICE80: This 64BitComponent OPT uses 32BitDirectory MM

From https://dev.azure.com/dnceng/public/_build/results?buildId=1631437&view=logs&jobId=1b89928a-2219-5ef9-602f-f95beb3da4dc&j=1b89928a-2219-5ef9-602f-f95beb3da4dc&t=39263dad-2be6-5f40-bde4-1bab0d7931b4

[joeloff]

Yeah its just

D:\a\_work\1\s\src\Installers\Windows\HostOptions\Product.wxs(53): error LGHT0204: ICE80: This 64BitComponent OPT uses 32BitDirectory MM [D:\a\_work\1\s\src\Installers\Windows\HostOptions\HostOptions.wixproj]
##[error]src\Installers\Windows\HostOptions\Product.wxs(53,0): error LGHT0204: (NETCORE_ENGINEERING_TELEMETRY=Build) ICE80: This 64BitComponent OPT uses 32BitDirectory MM

From https://dev.azure.com/dnceng/public/_build/results?buildId=1631437&view=logs&jobId=1b89928a-2219-5ef9-602f-f95beb3da4dc&j=1b89928a-2219-5ef9-602f-f95beb3da4dc&t=39263dad-2be6-5f40-bde4-1bab0d7931b4

You should fix this. Again, preprocessor condition that defines something like PFile=ProgramFilesFolder or ProgramFilesFolder64. The chain of directories will impact the GUID generation for components, so do not suppress the ICE error.

[joeloff]

Take a look at https://github.com/dotnet/installer/blob/661fdd30e9ba5de39b430d879d46ce00323a0ad5/src/redist/targets/packaging/windows/clisdk/variables.wxi#L26 for how to leverage the preprocessor

[joeloff]

Do you need to be concerned about support arm64 and x64 SxS on the same machine like we do with the runtimes/SDK? Because arm64 and x64 share the same hive, you have to do additional work to make sure x64 on arm64 installs into a subfolder, though I'm not sure what that implication would be for ANCM and if IIS even supports SxS with emulation.

[HaoK]

You should fix this. Again, preprocessor condition that defines something like PFile=ProgramFilesFolder or ProgramFilesFolder64. The chain of directories will impact the GUID generation for components, so do not suppress the ICE error.

Can you clarify what the fix we need to make here is? so is this complaining that some folders are not using the 64bit ones?

Do you need to be concerned about support arm64 and x64

I'm not sure, does it seem unreasonable for us to just only support arm64 and not drop x64 binaries on an arm64 machine? This might be something we need to ask the IIS team about I guess.

[joeloff]

You should fix this. Again, preprocessor condition that defines something like PFile=ProgramFilesFolder or ProgramFilesFolder64. The chain of directories will impact the GUID generation for components, so do not suppress the ICE error.

Can you clarify what the fix we need to make here is? so is this complaining that some folders are not using the 64bit ones?

Yes, for x64/arm64 you want to use the 64-bit versions of everything, including registry keys, unless you specifically need to target the 32-bit registry hive. For files, x64 and arm64 should use ProgramFiles64Folder always.

Starting from the SourceDir at the top, the full path is constructed for each file, this is known as the keypath. That value is then used to generate a stable GUID for the component which impacts things like reference counts, two products that install a component with the same key path must have the same GUID.

Do you need to be concerned about support arm64 and x64

I'm not sure, does it seem unreasonable for us to just only support arm64 and not drop x64 binaries on an arm64 machine? This might be something we need to ask the IIS team about I guess.

Definitely ask IIS team. I can imagine that just like hosting both x86 and x64 app pools someone might want to host arm64 and x64 app pools on the same machine. But I have no idea. There was a pretty big drive late in .NET 6 around x64 emulation on arm64 so that's why I brought it up.

[HaoK]

@dougbu do we have a weird build race condition here? My understanding of what I thought should happen was buildx64/arm64 should have already built the ANCM/outofproc dlls, I see that in the logs that all 3 x86/arm64/x86 ANCM is built properly...

But the installers would fail not seeing the arm64 ANCM dlls, so I got rid of the -nobuildNative, which now results in something in the installers build trying to consume outofproc dll while its trying to build it??

From the build installers job:

LINK : fatal error LNK1104: cannot open file 'D:\a\_work\1\s\artifacts\bin\OutOfProcessRequestHandler\arm64\Release\aspnetcorev2_outofprocess.dll' [D:\a\_work\1\s\src\Servers\IIS\AspNetCoreModuleV2\OutOfProcessRequestHandler\OutOfProcessRequestHandler.vcxproj]
##[error]LINK(0,0): error LNK1104: (NETCORE_ENGINEERING_TELEMETRY=Build) cannot open file 'D:\a\_work\1\s\artifacts\bin\OutOfProcessRequestHandler\arm64\Release\aspnetcorev2_outofprocess.dll'
  Finished generating code
  OutOfProcessRequestHandler.vcxproj -> D:\a\_work\1\s\artifacts\bin\OutOfProcessRequestHandler\ARM64\Release\aspnetcorev2_outofprocess.dll

Why is it trying to link before building the dll (or is this in parallel?)

[dougbu]

@HaoK the native projects shouldn't need to rebuild for the installers. Something is wonky with either OutOfProcessRequestHandler.vcxproj or the properties it's passed in this case. A binary log should help find what's causing the build and checking what else is running at the same time.

[HaoK]

Okay I guess it was some weirdness with building native twice, turning off parallel seems to be sufficient, i manually tried the installers for ANCM + hosting bundle + ANCM+IISExpress and they all behave as expected on the arm64 machine (IISExpress will fail since no matching verison of IIS installed).

For the purposes of the first pass of this PR (working/building installer), I think we should consider this mergeable

[HaoK]

Note: this was causing build issues from the HostOptions stuff that are now also reusing this wxi to be able to properly get the right 64/32 bit ProgramFiles, it doesn't look like we are using OOBBuildVersion anywhere since it was fine to just remove it (as BLDVERMINOR/MAJOR aren't being defined everywhere else). So I think this was just dead definitions

[HaoK]

We seem to be diverging from the Directory.Build.props which set installer version to 200 or 500, so I kept this the way we were before hardcoding to 400, but we need to make it at least 500 for ARM64, hence why we don't just use InstallerVersion here

[joeloff]

Most supported OS versions should have MSI 5.0 installed, but we've mostly stuck to 2.0 for some reason. It's possible that ANCM required features that were introduced in 4.0 which is why they default to 400, but I can't say for sure.

[HaoK]

This is another example of ARM64 perhaps not being fully correct, as TargetName doesn't seem to be defined for ARM64, where the other projects picked up the correct default

[HaoK]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).