[Dont merge] Add ARM64 targets for ANCM

[shirhatti]

Addresses #bugnumber (in this specific format)

[shirhatti]

A couple of issues so far:

• The arm64 ancm msi has the wrong bitness ancm included
• Schema file isn't included in the installer
• There's no way to test ancmv2 IISexpress installer as currently there's arm64 iisexpress build

[shirhatti]

@dotnet/aspnet-build Any suggestions on what's going wrong here? I'm specifically looking at the Windows ARM64 build failure where pretty much every project fails with the same issue

src\Analyzers\Analyzers\test\Microsoft.AspNetCore.Analyzers.Test.csproj(0,0): error NU1503: (NETCORE_ENGINEERING_TELEMETRY=Restore) Skipping restore for project 'D:\workspace\_work\1\s\src\Analyzers\Analyzers\test\Microsoft.AspNetCore.Analyzers.Test.csproj'. The project file may be invalid or missing targets required for restore.

I'm able to build the projects (including all the native projects that I've modified) through their respective build scripts .\build.cmd /p:Platform=arm64.

I've also tried modifying the sln file to add arm64 config section to each project to no avail.

Details

Regex to modify .sln file

Search: (^\t\t\{[0-9,A-F,-]{36}\}\.(Debug|Release)\|)(x86)(\.)(Build)(\.0 = (Debug|Release)\|Any CPU)$
Replace: $1$3$4$5$6\n$1ARM64$4$5$6\n$1ARM64$4ActiveCfg$6

[dougbu]

Real problem is AspNetCore.sln should never be used in CI builds.

D:\workspace\_work\1\s\src\Analyzers\Analyzers\test\Microsoft.AspNetCore.Analyzers.Test.csproj : error NU1503: Skipping restore for project 'D:\workspace\_work\1\s\src\Analyzers\Analyzers\test\Microsoft.AspNetCore.Analyzers.Test.csproj'. The project file may be invalid or missing targets required for restore. [D:\workspace\_work\1\s\AspNetCore.sln]

Root cause is you haven't updated eng/Build.props to include any projects in that build step.

[dougbu]

Please reset your preferences so that newlines at the ends of files are left alone. Then fix this and other changed files up. Right now at least, most developers seem to add newlines.

[shirhatti]

Ack. Will fix.

[dougbu]

Something further down the stack only conditionally builds AspNetCoreModuleShim. Missing that assembly leads to at least some of the build failures.

[shirhatti]

@jkotalik You may want to specifically review this and the changes to the Cpp.Common.Targets as well

[shirhatti]

@dougbu What do I do about the error where the ARM64 build fails because the ARM64 leg of the build doesn't produce a targeting pack.

I looked the Build.props and saw this comment which left me quite confused

<!-- This really shouldn't be here, but instead of harvesting from the intermediate/output directories, the targetting pack installer logic
harvests from a zip of the reference assemblies. Producing it in each leg ends up with multiple targeting packs
getting produced and the BAR will reject the build. Centralize building the targeting pack in the x86/x64 leg. -->
<ProjectToBuild Include="$(RepoRoot)src\Installers\Windows\TargetingPack\TargetingPack.wixproj" AdditionalProperties="Platform=arm64" />

[shirhatti]

On second thought, I think I got it. The requisite ARM64 ANCM bits already get built in the x64 build stage.

I assume I shouldn't build native as part of the ARM64 build? Is that correct?

[shirhatti]

I realize that this approach fails as well. Since the the x64 and and x86 builds happen in the same pipeline, we cheat by only building native assets once for all platforms as part of just the x64 build.

Since we're building ARM64 in a separate pipeline that won't work. Building the Microsoft.AspNetCore.Server.IIS package has native deps which relies on the native build having already run.

I can only think of some crazy ideas to fix this. I assume the build team wouldn't be happy with any of my suggestions 🤣

• Move the entire ARM64 build into same pipeline as x64/x86
• RID-split the Microsoft.AspNetCore.Server.IIS package and build each rid in it's own pipeline

[jkotalik]

RID-split the Microsoft.AspNetCore.Server.IIS package and build each rid in it's own pipeline

I think we'd have to go with this solution. We didn't have to rid split before because this only was on windows.

[dougbu]

Building the Microsoft.AspNetCore.Server.IIS package has native deps which relies on the native build having already run.

Correct. Could you describe why disabling native builds is necessary❔

Move the entire ARM64 build into same pipeline as x64/x86

Adding more to that job is a non-starter because that's one of the longest legs as it is.

Another possibility is to build the Windows native assets once in a separate job that all other Windows jobs depend on. That would take some care to upload all the relevant files to an AzDO artifact, download them, and place the files where managed projects and the installer builds expect them. Might get messy but would lengthen the build only slightly (for the job startup delay plus the download / file placement work).

[shirhatti]

Correct. Could you describe why disabling native builds is necessary❔

https://dev.azure.com/dnceng/public/_build/results?buildId=1026804&view=logs&j=2222de35-8455-5ef3-8655-d7b771ed54f9&t=661986e5-4210-5432-efd4-be70b326bea0

[dougbu]

@shirhatti ah, I thought you meant all native projects. The targeting pack and shared Fx bundles should not build for ARM64. Problem here is instead at https://github.com/dotnet/aspnetcore/pull/30680/files#diff-366b25472963c6b33188d84139f6c8997298c5adc857a2624ab0d26a2d87baf0R66 That change is incorrect because we already enable ARM64 *.wixproj builds in a separate block from the x64 / x86 one. Basically, we're now building too many *.wixproj projects for too many architectures.

You need to extend the *.wixproj build on ARM64 to include the IIS-related installers but that should be about it.

[pranavkm]

@HaoK could we close this PR now that you have a copy?