Refactor System.Reflection.MetadataLoadContext tests to work for single file

[MichalStrehovsky]

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

	// 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:

runtime/src/libraries/System.Diagnostics.FileVersionInfo/tests/System.Diagnostics.FileVersionInfo.Tests/System.Diagnostics.FileVersionInfo.Tests.csproj

Lines 46 to 49 in 8abc251

	<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.

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

	// 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:

runtime/src/libraries/System.Diagnostics.FileVersionInfo/tests/System.Diagnostics.FileVersionInfo.Tests/System.Diagnostics.FileVersionInfo.Tests.csproj

Lines 46 to 49 in 8abc251

	<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.

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-System.Reflection
Milestone:	-

Tagging subscribers to this area: @dotnet/area-system-reflection-metadata
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

	// 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:

runtime/src/libraries/System.Diagnostics.FileVersionInfo/tests/System.Diagnostics.FileVersionInfo.Tests/System.Diagnostics.FileVersionInfo.Tests.csproj

Lines 46 to 49 in 8abc251

	<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.

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-System.Reflection.Metadata, untriaged
Milestone:	-

[steveharter]

Linking #72917 and #27803

[steveharter]

Moving to v9 based on priority+resources.