How to get all the referenced assemblies using reflection ? (.net4)

Question

I've made a piece of code that gives me the referenced assemblies of one assembly (in .net5) and it was working greatly, it gave me for exemple if I use the File.WriteAllText method the assembly "System.IO.FileSystem" (this is by using the Assembly.GetReferencedAssemblies method).

But now I need to get this code to work on .NET4 (for Unity Engine). But i've seen that the myAssembly.GetReferencedAssemblies do not give the same output as in .NET5.

It now gives me only: myAssembly.dll and mscorlib.dll

And I cannot make it work to give me like previously all the referenced assemblies (for exemple System or System.IO ...)

Here's a simple example:

    using System.IO;

    public class Plugin {

         static Plugin() {

             // Just use the File class to keep the System.IO assembly reference
             File.WriteAllText("test", string.Empty);

         }

    }

    public static void Test() {

        string myPluginPath = "myAssembly.dll";

        // Load the assembly
        Assembly assembly = Assembly.LoadFrom(myPluginPath);

        // Get all the referenced assemblies
        foreach (AssemblyName name in assembly.GetReferencedAssemblies()) {

            Console.WriteLine(name.Name);

            // Different outputs:
            //
            // .NET 5
            // - System.IO.FileSystem
            // - ....
            // .NET 4
            // - mscorlib
            // - Plugin

        }

    }

Any idea how to make the myAssembly.GetReferencedAssemblies work on .net4 ? Thanks!

Please provide us with a [mcve] that shows us the output you're seeing with both .NET 4 and .NET 5. — Enigmativity, Jul 05 '21 at 11:42

György Kőszeg · Accepted Answer · 2021-07-05T17:30:54.523

Any idea how to make the myAssembly.GetReferencedAssemblies work on .net4?

System.IO.File resides in mscorlib.dll in .NET Framework so both versions work correctly. Why do you need the actual assembly names? You cannot rely on them across platforms.

On the other hand, if you need this to resolve assembly qualified type names, then you can do it by using the legacy assembly identities so Type.GetType("System.IO.File, mscorlib, Version=4.0.0.0") works also in .NET 5.

It's because even on the newer platforms there is an mscorlib.dll, which contains nothing but a bunch of [assembly:TypeForwardedTo(...)] attributes that provide a redirect to the new location.

But it will not work the other way around so do not expect that you can resolve the type File from a System.IO.FileSystem.dll in .NET Framework 4.0

Update after the comment:

In .NET Framework the best way for handling potentially harmful plugins is creating separate AppDomains for them with restricted permissions. Here is an example from my unit tests to create such a sandbox domain and here is an example usage. The AppDomains can even be unloaded along with their referenced assemblies.

The bad news is that this will not work in .NET 5 because starting with .NET Core you cannot create AppDomains anymore (not quite a problem if you already have a solution for .NET 5). But for the sake of completeness: starting with .NET Core 3.0 the AssemblyLoadContext type is the recommended way for handling plugins. Though it does not create a restricted environment the same way as AppDomain, you can use AssemblyDependencyResolver to control the assembly loading requests of the plugins.

I am actually doing a "plugin" or "modding" system with Unity. Basically I want to let the user create custom .dll and then just load them in the game. But I need to prevent the users to create dlls that could harm the other player's computer (by not allowing the dlls that use certain namespaces like System.IO or Interop Services (for the DllImport attribute)). Maybe there is another solution to analyse the assemblies in order to check if they have unsafe assemblies ? — NaolShow, Jul 05 '21 at 15:31

How to get all the referenced assemblies using reflection ? (.net4)

1 Answers1

Linked