MetadataLoadContext test has a clever trick to map runtime types to their MetadataLoadContext version by using Assembly.Location, opening them in a metadata context and finding the corresponding type. This doesn't work in single-file testing in general and NativeAOT in particular.
|
// Given a runtime Type, load up the equivalent in the Test MetataLoadContext. This is for test-writing convenience so |
|
// that tests can write "typeof(TestClass).Project()" and get the benefits of compile-time typename checking and Intellisense. |
|
// It also opens the possibility of sharing Reflection tests between different type providers with minimal fuss. |
|
public static Type Project(this Type type) |
|
{ |
|
if (type == null) |
|
return null; |
|
|
|
Assembly assembly = type.Assembly; |
|
string location = assembly.Location; |
|
if (PlatformDetection.IsNotBrowser && (location == null || location == string.Empty)) |
|
{ |
|
throw new Exception("Could not find the IL for assembly " + type.Assembly + " on disk. The most likely cause " + |
|
"is that you built the tests for a Jitted runtime but are running them on an AoT runtime."); |
|
} |
|
|
The best way forward would probably be to introduce a test assembly that will have all the types we need to project and to include it as Content. Like so:
|
<ProjectReference Include="..\System.Diagnostics.FileVersionInfo.TestAssembly\System.Diagnostics.FileVersionInfo.TestAssembly.csproj" Condition="'$(TargetOS)' != 'Browser'"> |
|
<OutputItemType>Content</OutputItemType> |
|
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> |
|
</ProjectReference> |
We can have the test types in both the test project and in the Content assembly - the projection would be updated to look in the Content assembly instead of Assembly.Location.
We'll probably need another Content assembly that will be a simulated CoreLib with whatever dummy content we need to make the test assembly build. It wouldn't be the first fake CoreLib in the runtime repo.
MetadataLoadContext test has a clever trick to map runtime types to their MetadataLoadContext version by using Assembly.Location, opening them in a metadata context and finding the corresponding type. This doesn't work in single-file testing in general and NativeAOT in particular.
runtime/src/libraries/System.Reflection.MetadataLoadContext/tests/src/TestUtils/TestUtils.JittedRuntimes.cs
Lines 11 to 26 in 57bfe47
The best way forward would probably be to introduce a test assembly that will have all the types we need to project and to include it as Content. Like so:
runtime/src/libraries/System.Diagnostics.FileVersionInfo/tests/System.Diagnostics.FileVersionInfo.Tests/System.Diagnostics.FileVersionInfo.Tests.csproj
Lines 46 to 49 in 8abc251
We can have the test types in both the test project and in the Content assembly - the projection would be updated to look in the Content assembly instead of Assembly.Location.
We'll probably need another Content assembly that will be a simulated CoreLib with whatever dummy content we need to make the test assembly build. It wouldn't be the first fake CoreLib in the runtime repo.