[NativeAOT] Update ILCompiler paths to handle PublishAotUsingRuntimePack=true

[filipnavara]

When using PublishAotUsingRuntimePack we need to update the logic to get native libraries from the runtime pack, and not to replace the framework files with the host ILCompiler ones.

This PR is minimal attempt that does the job but we can do better. There's a lot of logic for the framework file substitution that is not necessary when using the runtime pack since we already start with the correct set of files.

cc @akoeplinger

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When using PublishAotUsingRuntimePack we need to update the logic to get native libraries from the runtime pack, and not to replace the framework files with the host ILCompiler ones.

This PR is minimal attempt that does the job but we can do better. There's a lot of logic for the framework file substitution that is not necessary when using the runtime pack since we already start with the correct set of files.

cc @akoeplinger

Author:	filipnavara
Assignees:	-
Labels:	community-contribution, area-NativeAOT-coreclr
Milestone:	-

[ivanpovazan]

Why aren't PrivateSdkAssemblies included in DefaultFrameworkAssemblies in this case?

[filipnavara]

It's not exactly intuitive but RuntimePackAsset already contains the files that end up in PrivateSdkAssemblies, so FrameworkAssemblies already contains the union of the two sets.

[filipnavara]

Also, FrameworkAssemblies itself is not used beyond this point, so the additional assemblies included in it have no effect.

[ivanpovazan]

Also, FrameworkAssemblies itself is not used beyond this point, so the additional assemblies included in it have no effect.

Sorry, I got confused with this.
Aren't FrameworkAssemblies used through DefaultFrameworkAssemblies to populate IlcReference:

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

Line 155 in ea94440

<IlcReferenceInclude="@(DefaultFrameworkAssemblies)" />

[filipnavara]

DefaultFrameworkAssemblies is used beyond the point and it's expected to contain the union of lib/net8.0/*.dll and native/*.dll from the runtime pack.

In the case of PublishAotUsingRuntimePack=false these come from two different source directories and get merged into one DefaultFrameworkAssemblies item group.

In the case of PublishAotUsingRuntimePack=true all the files in the DefaultFrameworkAssemblies item group come from the RuntimePackAsset item group which already contains both the lib/net8.0/*.dll files and the native/*.dll files.

I was just trying to clarify that FrameworkAssemblies in the PublishAotUsingRuntimePack=true case will also include PrivateSdkAssemblies (native/*.dll), while in the PublishAotUsingRuntimePack=false case it won't include those files. However, FrameworkAssemblies itself is not used beyond this point, so the distinction doesn't matter.

[filipnavara]

I can just rewrite it as to make it clearer:

- <FrameworkAssemblies Include="@(RuntimePackAsset)" Condition="'%(Extension)' == '.dll'" />- <DefaultFrameworkAssemblies Include="@(FrameworkAssemblies)" />+ <DefaultFrameworkAssemblies Include="@(RuntimePackAsset)" Condition="'%(Extension)' == '.dll'" />

[ivanpovazan]

Thank you very much for the clarification!

Regarding your last comment:

I can just rewrite it as to make it clearer:

Would it make sense to keep having a single ItemGroup and just distinguish what gets included in DefaultFrameworkAssemblies based on PublishAotUsingRuntimePack value?

[MichalStrehovsky]

Would it make sense to name this IlcPrivateSdkPath since that's where PrivateSdkAssemblies come from?

Suggested change

	<PrivateSdkAssembliesInclude="$(IlcFrameworkSdkPath)*.dll"/>
	<PrivateSdkAssembliesInclude="$(IlcPrivateSdkPath)*.dll"/>

[filipnavara]

Superceded by #86652