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

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.

Linking #72917 and #27803

Moving to v9 based on priority+resources.

@MichalStrehovsky

@MichalStrehovsky is this still a valid scenario and is the possible implementation below still valid?

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.

@MichalStrehovsky

@MichalStrehovsky is this still a valid scenario and is the possible implementation below still valid?

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.

Yes, it's still a test gap and including as Content should work. E.g. the System.Diagnostics.FileVersionInfo.Tests test does that to include System.Diagnostics.FileVersionInfo.TestAssembly (a test assembly file that is loaded to check its version).

@jkotas

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.

What about just including System.Runtime.dll with the test assembly. @jkotas and I were discussing improving the test coverage with more behavior diffing in #116080 (comment) and we have other reasons to include it.

So we could build a test assembly of interesting types, and include it as content, along with the minimal set of references it required to build.

I guess including the test assembly itself as content could also solve this, but I like the better factoring of having an assembly of only interesting test types.

What about just including System.Runtime.dll

Yes, including System.Runtime ref assembly should be enough.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// 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.");
	}

	<ProjectReference Include="..\System.Diagnostics.FileVersionInfo.TestAssembly\System.Diagnostics.FileVersionInfo.TestAssembly.csproj" Condition="'$(TargetOS)' != 'Browser'">
	<OutputItemType>Content</OutputItemType>
	<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
	</ProjectReference>

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

Description

Activity

steveharter commented on Nov 4, 2022

steveharter commented on Aug 2, 2023

steveharter commented on Jul 24, 2024

MichalStrehovsky commented on Jul 25, 2024

ericstj commented on Jun 3, 2025

jkotas commented on Jun 3, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions