Switch the order of AOT SDK and framework assemblies

[SingleAccretion]

When you have built a CoreCLR CoreLib, it "poisons" the build s.t. running libraries tests with NAOT becomes impossible.

This is because $(IlcFrameworkPath) draws from a shared framework that contains the CoreCLR CoreLib, while it should use the CoreLib from the AOT SDK.

This targeted change changes the order in which these two assemblies get passed to ILC and allows one to use "/p:TestNativeAot=true" without additional workarounds.

This may be a bit controversial as it has the potential to hide problems with bad build states, so I am putting this up more for discussion.

[ghost]

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

Issue Details

---

When you have built a CoreCLR CoreLib, it "poisons" the build s.t. running libraries tests with NAOT becomes impossible.

This is because $(IlcFrameworkPath) draws from a shared framework that contains the CoreCLR CoreLib, while it should use the CoreLib from the AOT SDK.

This targeted change changes the order in which these two assemblies get passed to ILC and allows one to use "/p:TestNativeAot=true" without additional workarounds.

This may be a bit controversial as it has the potential to hide problems with bad build states, so I am putting this up more for discussion.

Author:	SingleAccretion
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[MichalStrehovsky]

I think this is a good change. The existing ordering was already arbitrary so changing the arbitrary order to something that can fix an issue people could run into in their inner loop is fine by me. Thanks!