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:

using System;
using System.IO;

namespace GetTypeRepro
{
    internal class Program
    {
        static void Main(string[] args)
        {
            foreach (bool throwOnError in new[] { 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 (string invalidTypeName in invalidTypeNames)
            {
                _ = typeof(string).Assembly.GetType(invalidTypeName, throwOnError: false);
                Console.WriteLine("No exception was thrown because throwOnError was set to false");
            }

            foreach (string invalidTypeName in invalidTypeNames)
            {
                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.