Assembly.GetExecutingAssembly, AppDomain.CurrentDomain and similar

[tomasherceg]

Are there any plans to include the following classes and methods in near future? I am porting my framework (http://github.com/riganti/redwood) to .NET Core and I miss these methods.

• Assembly.GetReferencedAssemblies
• Assembly.GetExecutingAssembly
• Assembly.GetEntryAssembly
• Assembly.GetCallingAssembly
• Assembly.CreateInstance
• Assembly.Load which takes byte array or a stream
• AppDomain.CurrentDomain.GetAssemblies
• AppDomain.CurrentDomain.AssemblyResolve

Or is there another way in the new .NET Core how to list all loaded assemblies, get the assembly of method that is being executed or a calling method etc.?

[HellBrick]

+1, at least for some of them. Personally, I use Assembly.GetEntryAssembly() (for logging and other diagnostics purposes) and AppDomain.CurrentDomain.GetAssemblies() (for discovering modules in the loaded assemblies) fairly often.

[tomasherceg]

Maybe the more important question is: "Is it correct to use the old reflection API, or is there a better API to do the tasks?"
I have saw ILibraryManager etc. however there are not much information about this yet.

[HellBrick]

I decided to take a look at the way ASP.NET MVC looks up controller classes. It indeed uses ILibraryManager to get the names of the assemblies that reference MVC stuff, does Assembly.Load() for them and then uses Assembly.DefinedTypes to search for the types of interest. See DefaultAssemblyProvider and DefaultControllerTypeProvider for details.

I just haven't figured out where to get an instance of ILibraryManager yet ;)

[HellBrick]

Got it, at least partially:

internal static class ServiceProviderExtensions
{
    public static T GetService<T>( this IServiceProvider serviceProvider )
    {
        return (T) serviceProvider.GetService( typeof( T ) );
    }
}

public class Program
{
    private readonly IServiceProvider _serviceProvider;

    public Program( IServiceProvider serviceProvider )
    {
        _serviceProvider = serviceProvider;
    }

    public void Main( string[] args )
    {
        var libraryManager = _serviceProvider.GetService<ILibraryManager>();

        // and this is at least some kind of info about the entry point
        var applicationEnvironment = _serviceProvider.GetService<IApplicationEnvironment>();
        string appName = applicationEnvironment.ApplicationName;        
    }
}

I wonder if there is some static property somewhere that gets this default instance of IServiceProvider though, because I can see how passing something like ILibraryManager all the way from the entry point to wherever it's actually needed can be a bit annoying.

[tomasherceg]

I wouldn't mind passing the ILibraryManager instance to the place where I need it - I use IoC/DI containers in my apps so I am used to the pattern that each class requires all its dependencies. That's not such a problem, the container solves the thing for you.

However thanks for the sample how they do it in MVC - I have tried it but throws some weird exceptions. I'll need to dig into it in more detail.

[akoeplinger]

ILibraryManager is a DNX concept and it is indeed passed via DI there, but it's not available on plain .NET Core.

[tomasherceg]

I know - there are two parts of this question.
The first part is how to do it in pure .NET Core and if there are some plans to add the API mentioned before.
The second part is how to deal with this right now in ASP.NET application that will be running on DNX.

I believe I can solve the second part and use the ILibraryManager, however I'd like to know the answer to the original question - whether it is planned to add the API soon or how shall we deal with with the problem.

[xanather]

I was surprised when these API's didn't exist in .NET Core. Why not? Some project are looking to support .NET Core, will it eventually be added or do we need to implement it ourselves here?

Edit: If it's not going to added I think it should be stated here to prevent future confusion from others trying to port things over.

[xanather]

Using type.GetTypeInfo() helps with this issue for obtaining an Assembly object instances if anyone else comes along it.

[exyi]

It's quite strange that Assembly.Load(byte[]) exists in CoreCLR project: https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Reflection/Assembly.cs#L392
Can someone explain me why it's there and we can't use it?

[nguerrera]

cc @gkhanna79

@exyi It actually gets modified to be internal in the build process. It is complicated by various factors around how this code gets shared in many different configurations.

.NET Core does expose a mechanism to load byte arrays. Take a look at the System.Runtime.Loader package which provides AssemblyLoadContext

Note that the design there is to allow an app-model host such as DNX a way to take care of resolution in the way that is appropriate for its environment. So if you are running in DNX, you'll want to go through their loader API, which is implemented using AssemblyLoadContext.

As for the other APIs requested:

• GetReferencedAssemblies is not something that I recall discussing so I'll have to check with others on the team.
• GetEntryAssembly is very sensitive to the App Model. Do you really want the AssemblyInfo or are you looking for the application base path? You can use AppContext.BaseDirectory for the latter.
• GetCallingAssembly has all sorts of problems. For one, it is not well defined due to inlining (see Remarks). For another, code that changes behavior based on the calling assembly is extremely hard to reason about. If you're using it for diangostics, consider the drastically lighter weight Caller Information.
• GetExecutingAssembly is something we will likely bring back. On current platforms due to lack of optimization, it ends up being much slower than the equivalent typeof(CurrentType).GetTypeInfo().Assembly. However, it is possible to fix the code generation and we will consider doing that for more compatibility with existing source code. In the meantime, just do the transformation yourself and your code will speed up on all platforms.
• AssemblyResolve is replaced by AssemblyLoadContext (see above)
• AppDomain.GetAssemblies could theoretically become AssemblyLoadContext.GetAssemblies(), but I'll defer to @gkhanna79 on whether that would be a good idea.

[HellBrick]

@nguerrera

GetEntryAssembly is very sensitive to the App Model. Do you really want the AssemblyInfo or are you looking for the application base path? You can use AppContext.BaseDirectory for the latter.

What I really want is the name of the assembly that is the logical entry point of my code that's being run. If the code is being run in a simple console app, then I want the name of the console app assembly. If the code is being run in a test harness, then I want the name of the test assembly my test is located in. If the code is being run in an IIS-hosted website, I want the name of the website assembly. That's really more than GetEntryAssembly allows today, so I have to jump through some hoops to do it at the moment (some dirty hacks based on examining the call stack).

And even though I said I want the name of the assembly, I can easily imagine scenarios where I would also need its version, so I guess having the full AssemblyInfo can be useful here.