Weird FileLoadException when using old library and .NET 10

[zvirja]

Description

I stumbled upon a very weird error which I believe is a regression in the runtime. It happens when I use a very old pre-compiled library and invoke a very ordinary method inside of it.

Reproduction Steps

1. Build and run the attached program using .NET 10.0.201 SDK

ClrBugRepro.zip

Expected behavior

Program just works

Actual behavior

Program fails with an extremely weird error:

C:/Projects_Playground/ClrBugRepro/bin/Debug/net10.0/ClrBugRepro.exe
Unhandled exception. System.IO.FileLoadException: Unable to load file 'C:\Projects_Playground\ClrBugRepro\bin\Debug\net10.0\C5.dll'.
   at C5.TreeSet`1.Node.CopyNode(Node& cursor, Int32 maxsnapid, Int32 generation)
   at C5.TreeSet`1.Node.CopyNode(Node& cursor, Int32 maxsnapid, Int32 generation)
   at C5.TreeSet`1.Update(T item, T& olditem)
   at Program.<Main>$(String[] args) in C:\Projects_Playground\ClrBugRepro\Program.cs:line 7

It totally makes no sense to say that file is not found when you are already deeply inside the assembly 🤯

Regression?

Yes, it is a regression. It works perfectly fine with .NET 6 and .NET 8. The regression starts somewhere in .NET 9.

Known Workarounds

None if I want to use the existing DLL.

I tried re-compiling it using modern SDK and it seems it fixed the issue. Yet I want to use the original old NuGet package, as otherwise it's a bit of a mess.

Configuration

I don't think environment is relevant, but:

• Run on Windows 11
• SDK 10.0.201
• x64

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @elinor-fung
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

It totally makes no sense to say that file is not found when you are already deeply inside the assembly

Agreed. This is very questionable.

The actual error hidden behind the generic file load exception:

System.IO.FileLoadException: The given assembly name was invalid.
File name: 'C5.Tests,PublicKey=00240000048000009400000006020000002400005253413100040000010001002d07581667cbf8caf9786ac8d5257eb2c77eb2643a1af1bb89d4286e27a3ff5d805408c9f1a0a392d2f478ca2b9c68e43cdcdcea2d7cf0618dd8ba48858bf5fc74c7fc2af7a29f936398c0f61a2165d08ac4fcc8e8ad04e24633b7ca31a7c13f750ae75e53cea55ced97d3289fd100dbe2661a802bf8bd2acb0b6893ef3fb79c,PublicKeyToken=282361b99ded7e8e'
   at System.Reflection.AssemblyNameParser.Parse(ReadOnlySpan`1 name)

That is invalid because both PublicKey and PublicKeyToken are specified. Constructing an AssemblyName with that string would hit the same error.

This is while looking at friend assemblies:

coreclr.dll!RealCOMPlusThrowHR(HRESULT hr, unsigned int resID, const wchar_t * wszArg1, const wchar_t * wszArg2, const wchar_t * wszArg3, const wchar_t * wszArg4, const wchar_t *)	C++
coreclr.dll!FriendAssemblyDescriptor::CreateFriendAssemblyDescriptor(PEAssembly * pAssembly)	C++
coreclr.dll!Assembly::CacheFriendAssemblyInfo()	C++
coreclr.dll!Assembly::GetFriendAssemblyInfo()	C++
coreclr.dll!Assembly::IgnoresAccessChecksTo(Assembly * pAccessedAssembly)	C++
coreclr.dll!AssemblyOrFriendAccessAllowed(Assembly * pAccessingAssembly, Assembly * pTargetAssembly, FieldDesc * pOptionalTargetField, MethodDesc * pOptionalTargetMethod, MethodTable * pOptionalTargetType)	C++
coreclr.dll!ClassLoader::CheckAccessMember(AccessCheckContext * pContext, MethodTable * pTargetMT, Assembly * pTargetAssembly, unsigned long dwMemberAccess, MethodDesc * pOptionalTargetMethod, FieldDesc * pOptionalTargetField, const AccessCheckOptions & accessCheckOptions)	C++
coreclr.dll!ClassLoader::CanAccess(AccessCheckContext * pContext, MethodTable * pTargetMT, Assembly * pTargetAssembly, unsigned long dwMemberAccess, MethodDesc * pOptionalTargetMethod, FieldDesc * pOptionalTargetField, const AccessCheckOptions & accessCheckOptions)	C++
coreclr.dll!CEEInfo::getCallInfo(CORINFO_RESOLVED_TOKEN * pResolvedToken, CORINFO_RESOLVED_TOKEN * pConstrainedResolvedToken, CORINFO_METHOD_STRUCT_ * callerHandle, CORINFO_CALLINFO_FLAGS flags, CORINFO_CALL_INFO * pResult)	C++
[Inline Frame] clrjit.dll!Compiler::eeGetCallInfo(CORINFO_RESOLVED_TOKEN * flags, CORINFO_RESOLVED_TOKEN *)	C++
clrjit.dll!Compiler::impImportBlockCode(BasicBlock * block)	C++
clrjit.dll!Compiler::impImportBlock(BasicBlock * block)	C++
clrjit.dll!Compiler::impImport()	C++
clrjit.dll!Compiler::fgImport()	C++
[Inline Frame] clrjit.dll!Phase::Run()	C++

In the C5 3.0.0 package, the name is valid:

[assembly: InternalsVisibleTo("C5.Tests")]

In the C5 2.5.3 package (and presumably before), the name is the invalid one:

[assembly: InternalsVisibleTo("C5.Tests,PublicKey=00240000048000009400000006020000002400005253413100040000010001002d07581667cbf8caf9786ac8d5257eb2c77eb2643a1af1bb89d4286e27a3ff5d805408c9f1a0a392d2f478ca2b9c68e43cdcdcea2d7cf0618dd8ba48858bf5fc74c7fc2af7a29f936398c0f61a2165d08ac4fcc8e8ad04e24633b7ca31a7c13f750ae75e53cea55ced97d3289fd100dbe2661a802bf8bd2acb0b6893ef3fb79c,PublicKeyToken=282361b99ded7e8e")]

I'm not sure what changed here between 8.0 and 9.0 (that name is and has always been invalid) so that we end up erroring out. But we should probably not fail on an invalid friend assembly name for an assembly that we successfully loaded otherwise and are currently running.

[jkotas]

I'm not sure what changed here between 8.0 and 9.0

It fails for me in .NET 6.0 too. The behavior change likely occurred in early .NET Core versions, maybe even in .NET Core 1.0.

that name is and has always been invalid

.NET Framework assembly name parsers accept some invalid assembly names, including this one. Try to run new AssemblyName("... the invalid name from the repro ..."). It will run successfully on .NET Framework.

.NET Core switched to a single well tested assembly name parser that rejects the invalid assembly names correctly.

we should probably not fail on an invalid friend assembly name

I think we do want to fail on invalid friend assembly names, but with a better exception message. We are losing the good exception message due to HRESULT / Exception roundtrips. We may want to look into avoiding the lossy roundtrips to make the diagnostic experience better here.

[elinor-fung]

It fails for me in .NET 6.0 too.

Oh, interesting. I was not seeing the failure with .NET 8.0

I think we do want to fail on invalid friend assembly names, but with a better exception message.

Definitely agreed on the better error message. If this was a check we added such that assemblies that worked before would no longer, I was thinking we might want to re-evaluate impact or retroactively breaking change doc as well.

[elinor-fung]

The error path has been there (since at least 6.0, probably before). In this specific case, we are now going down that path for the access check because MemberwiseClone is now also internal (instead of just protected) as part of #95233.

Simple way to see this:

[assembly: InternalsVisibleTo("Broken,PublicKey=00240000048000009400000006020000002400005253413100040000010001002d07581667cbf8caf9786ac8d5257eb2c77eb2643a1af1bb89d4286e27a3ff5d805408c9f1a0a392d2f478ca2b9c68e43cdcdcea2d7cf0618dd8ba48858bf5fc74c7fc2af7a29f936398c0f61a2165d08ac4fcc8e8ad04e24633b7ca31a7c13f750ae75e53cea55ced97d3289fd100dbe2661a802bf8bd2acb0b6893ef3fb79c,PublicKeyToken=282361b99ded7e8e")]

internal class Program
{
    private static void Main(string[] args)
    {
        var test = new Program();
        test.MemberwiseClone();
    }
}