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.

[tmds]

@wtgodbe if it is intentional, then this is all good.

I had created an issue in runtime dotnet/runtime#111997 and the feedback there was that even without code crossgen2 produces R2R images, which is true.

Here we learned that the without code, crossgen2 gets skipped.

cc @jkotas @omajid

[jkotas]

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

This was introduced in dotnet/sdk#3099 . It probably does not hurt, but it does not help either. The PR description describes it as a workaround for PDB generation issue. I suspect that the PDB generation issue does not exist anymore.

cc @dotnet/crossgen-contrib