Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assembly.GetType(string, bool, bool) throws unexpected FileLoadException on NET9 #113534

Closed
DoctorVanGogh opened this issue Mar 14, 2025 · 3 comments · Fixed by #114228
Closed
Assignees
Labels
area-System.Reflection binaryformatter-migration Issues related to the removal of BinaryFormatter and migrations away from it regression-from-last-release
Milestone

Comments

@DoctorVanGogh
Copy link

DoctorVanGogh commented Mar 14, 2025

Description

When using Assembly.GetType(string, bool, bool) (in NET9) you can get unexpected FileLoadException depending on the input.

Depending on the passed in string parameter the method either succeeds (or fails) to look up a type, or throws an exception. Throwing that exception under those circumstances is certainly unexpected.

According to the documentation a FileLoadException will occur when

FileLoadException
name requires a dependent assembly that was found but could not be loaded.

alas - again according to the documentation,

This method only searches the current assembly instance

Specifically this occurs when using mscorlib as assembly to call things on. That assembly certainly should NOT have a problem "loading".

Reproduction Steps

Simple console program demonstrating the issue:

namespace Foo {
    internal class Program {
        static void Main(string[] args) {
            var mscorLibAssembly = typeof(string).Assembly;

            mscorLibAssembly.GetType("a,b", false, false);      // wont throw
            mscorLibAssembly.GetType("a,b,c", false, false);    // will throw
        }
    }
}

It seems, as soon as there are three (or more) , in the name parameter the method invocation throws.

Expected behavior

The method should certainly not throw a FileLoadException - because that indicates an issue with the probed assembly (here mscorlib) itself.

It might be reasonable to throw an ArgumentException because at least the docs state that this might occur

ArgumentException
name is invalid.

although "invalid" is not explained any further.

Preferably the method should not throw and just return null for a found type if the input is gibberish. Other runtimes - specifically NetFramework - simply returned null here.

Actual behavior

The method throws an unexpected exception FileLoadException on certain parameters.

Regression?

Yes. The method - and example code - will not throw an exception under previous versions of .NET (checked with .NET Framework 4.7.2 & .NET 8).

Known Workarounds

none

Configuration

NET 9.0.2

Other information

No response

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Mar 14, 2025
Copy link
Contributor

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

@jkotas
Copy link
Member

jkotas commented Mar 14, 2025

Looks like a regression introduced by #100094 . @adamsitnik Could you please take a look?

@ericstj ericstj removed the untriaged New issue has not been triaged by the area owner label Mar 17, 2025
@ericstj ericstj added this to the 10.0.0 milestone Mar 17, 2025
@ericstj ericstj added the binaryformatter-migration Issues related to the removal of BinaryFormatter and migrations away from it label Mar 17, 2025
Copy link
Contributor

Tagging subscribers to 'binaryformatter-migration': @adamsitnik, @bartonjs, @jeffhandley, @terrajobst

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Reflection binaryformatter-migration Issues related to the removal of BinaryFormatter and migrations away from it regression-from-last-release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants