Search code examples
.netdll.net-corecilecma

What is the difference between a .NET framework DLL and a .NET core DLL? Why do they need seperate runtimes?

When inspecting a .NET Core DLL and .NET Framework DLL using ildasm, they both seem very similar. The only difference I could see is the references (the .NET Framework DLL references mscorlib).

This makes sense, since both have to conform to ECMA-335. However, I don't understand how the runtime knows to use the .NET Core runtime, or .NET framework runtime when it loads a DLL for the first time. I also don't really see any reason why the .NET Framework wouldn't be able to run the .NET Core DLLs => as long as it can find the references, they must all be ECMA-335 DLLs.

Solution

  • There’s not a real difference, which is why libraries compiled against .NET Standard can be run on both runtimes.

    The differences are mainly that .NET Core libraries believe System.String comes from System.Runtime, and .NET Framework libraries believe it comes from mscorlib. With proper type-forward shim assemblies both runtimes can run libraries compiled for the other one... right up until they get a MissingMethodException or a TypeNotFoundException because the library used something only available on one of the runtimes (new methods in .NET Core, or methods left out of .NET Core that are present in .NET Framework).

    The runtime differences are more subtle:

    • .NET Core doesn’t have multiple AppDomains per process
    • .NET Core has System.Span as a special type in the runtime for better performance
    • .NET Framework has one GAC for 4.0 through 4.8
    • .NET Core maintains individual copies of Shared Frameworks for each patch release (for app-specific version locking)
    • .NET Framework GAC wins
    • .NET Core app-local file wins
    • .NET Core no longer uses CAS / partial trust
    • etc