GetType: keep throwing same exceptions as .NET 8

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.

[adamsitnik]

Keep throwing the same exceptions as we did in .NET 8. Namely:

• When using Type.GetType, always throw FileLoadException for invalid assembly names no matter what throwOnError is set to.
• When using Assembly.GetType, throw only when throwOnError is set, and ArgumentException (not FileLoadException)

fixes#113534

FWIW The app I've used for testing:

Details

usingSystem;usingSystem.IO;namespaceGetTypeRepro{internalclassProgram{staticvoidMain(string[]args){foreach(boolthrowOnErrorinnew[]{true,false}){try{_=Type.GetType("System.Object, System.Runtime, Version=x.y",throwOnError);}catch(FileLoadException){Console.WriteLine($"FileLoadException was thrown because provided assembly name was incorrect, despite throwOnError set to {throwOnError}.");}}string[]invalidTypeNames=["System.Object, System.Runtime, Version=x.y","a,b","a,b,c"];foreach(stringinvalidTypeNameininvalidTypeNames){_=typeof(string).Assembly.GetType(invalidTypeName,throwOnError:false);Console.WriteLine("No exception was thrown because throwOnError was set to false");}foreach(stringinvalidTypeNameininvalidTypeNames){try{typeof(string).Assembly.GetType(invalidTypeName,throwOnError:true);}catch(ArgumentException){Console.WriteLine("ArgumentException was thrown because type names passed to Assembly.GetType() must not specify an assembly.");}}}}}

[Copilot]

Pull Request Overview

This PR ensures that the exception behavior stays consistent with .NET 8 by differentiating between the exceptions thrown when using Type.GetType versus Assembly.GetType for invalid assembly names. Key changes include:

• Updating tests in GetTypeTests.cs to validate that FileLoadException is always thrown by Type.GetType regardless of throwOnError and that Assembly.GetType behaves as specified.
• Modifying TypeNameParser.cs to check if a top-level assembly was provided and to throw either FileLoadException or ArgumentException based on that.
• Adding and propagating the TopLevelAssemblyWasProvided property in TypeNameResolver.cs and TypeNameResolver.CoreCLR.cs.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
tests/System.Reflection.Tests/GetTypeTests.cs	Updated tests to assert correct exceptions for invalid assembly names.
System/Reflection/Metadata/TypeNameParser.cs	Adjusted parsing logic and exception throwing based on assembly name validity and top-level assembly presence.
System/Reflection/TypeNameResolver.cs	Added a TopLevelAssemblyWasProvided property to support the new validation logic.
System/Reflection/TypeNameResolver.CoreCLR.cs	Propagated the TopLevelAssemblyWasProvided flag to the parser call.

[dotnet-policy-service]

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

[jkotas]

Thank you!

[jkotas]

/ba-g known issues

[agocke]

Looks like this PR forgot to adjust the Native AOT implementation as well

[ericstj]

Lots of the failures in this build were in the test touched https://dev.azure.com/dnceng-public/public/_build/results?buildId=1005140&view=results

/Users/runner/work/1/s/.packages/microsoft.dotnet.helix.sdk/10.0.0-beta.25203.1/tools/azure-pipelines/AzurePipelines.MultiQueue.targets(44,5): error : Test System.Reflection.Tests.GetTypeTests.GetType_InvalidAssemblyName has failed. Check the Test tab or this console log: https://helix.dot.net/api/2019-06-17/jobs/0e93cafc-9702-4366-9278-169703aa02b7/workitems/System.Reflection.Tests/console

[jkotas]

The build analysis gave up on parsing all test failures. The ones that it did parse were all known except one that I have looked at and matched with a known issue.