Some ASP.NET Core shared framework assemblies are no longer crossgenned.

[tmds]

As part of our test suite, we have a test that checks .NET's dlls are R2R compiled.

This is no longer the case for these shared framework assemblies:

Microsoft.AspNetCore.Metadata.dll
Microsoft.AspNetCore.ResponseCaching.Abstractions.dll

For the composite framework they are still crossgenned. The build is producing these composite crossgenned assemblies at artifacts/obj/Microsoft.AspNetCore.App.Runtime.Composite/Release/linux-x64/. They are not produced for the shared framework at artifacts/obj/aspnetcore-sfx/Release/linux-x64/R2R.

cc @dougbu

[dougbu]

@tmds I'm not on the ASP.NET team these days. what question did you have for me here❓

/cc @wtgodbe in case you need ASP.NET build team help

[tmds]

@dougbu @wtgodbe the two mentioned assemblies are no longer r2r compiled for the 10.0 ASP.NET shared framework (while the other ones are). This is probably a regression. Can someone take a look?

[wtgodbe]

I wonder if this is related to switching to use the Shared Framework SDK - @jkoritzinsky what's the purpose of this file? https://github.com/dotnet/aspnetcore/blob/main/src/Framework/App.Runtime/src/PartialCompositeAssemblyList.txt

[jkoritzinsky]

That file is for the "composite image" tarball that's used for some Alpine Linux scenarios. The goal for that tarball was to get the highest performance from R2R with the least size impact using the "composite R2R" mode. That's unrelated to the regular ASP.NET Core shared framework, which shouldn't use that list.

[wtgodbe]

@tmds is this still showing up? Going to try to investigate this week

[tmds]

Yes, this is still showing up.

To check if an assembly is crossgenned you can use PEReader and check PEHeaders.CorHeader.ManagedNativeHeaderDirectory.Size != 0.

[wtgodbe]

Confirmed in the binlog that these assemblies do get passed to the PrepareForReadyToRunCompilation task, which doesn't include them in its output items to publish - only in ReadyToRunAssembliesToReference. Trying to figure out why.

[wtgodbe]

Current theory is that the !HasILCode part of the condition here is firing: https://github.com/dotnet/sdk/blob/e97ef7da99e1a625e7bc38559d3ce83a86bceb8c/src/Tasks/Microsoft.NET.Build.Tasks/PrepareForReadyToRunCompilation.cs#L479

Since these 2 assemblies just declare interfaces & don't have any implementation code. Trying to confirm/see if that's expected. E.g. https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/ResponseCaching.Abstractions/src/IResponseCachingFeature.cs is the only C# file in ResponseCaching.Abstractions

It makes sense that this would have changed w/ our switch to the SharedFx SDK, since we used to manually construct the list of files to pass to the crossgen tool.

[wtgodbe]

@tmds Is this change causing you issues, or did you just want to confirm whether or not this is a regression? If I can confirm my suspicion from the above comment, it sounds like this is expected/by-design

[wtgodbe]

Confirmed this is more-or-less by design. There's no code in those 2 assemblies, so crossgening them wouldn't really have any benefit. Going to close this as by-design, but feel free to open if it's causing issues for source-build.