Equivalent for AppDomain.CurrentDomain.GetAssemblies().SelectMany(a => a.GetTypes())

[DmitrySikorsky]

Hi! I have to get all implementations (classes) of some interface. How I can do that? Now I only can to make it for current assembly (project), but the goal is to have it in separate project:

public T GetRepository()
{
foreach (Type type in typeof(T).GetTypeInfo().Assembly.GetTypes())
if (typeof(T).IsAssignableFrom(type) && type.GetTypeInfo().IsClass)
return (T)Activator.CreateInstance(type);

return default(T);
}

[DmitrySikorsky]

The only idea we have is to parse json config files for dependencies and try to get that assemblies. But this looks to be strange.

[MattWhilden]

I presume that this is for some sort of Add In model? Having a better idea of your use case is probably helpful.

As a side note: patterns like this are much harder (but not impossible!) to support in a world where you'd want to use .Net Native and our ahead of time compiler.

[MattWhilden]

/cc @weshaggard @dsplaisted

[davidfowl]

We've always had problems in the past with this API where calling it too early would miss some types that were loadable but not loaded at the time of the call. In ASP.NET there was always BuildManager.GetReferencedAssemblies, that basically returned a list of all the assemblies (the entire closure) referenced by the application (including the application). That was a more accurate way to find things since it wouldn't miss the simple case where you had an application and a class library as a dependency, with the plugin defined in the class library but not loaded as yet.

It's also a pretty bad if you were forced to load all of the assemblies into the app domain eagerly. In the dnx, we came up with an API that would allow reasoning about the dependency graph of the application without eagerly loading all assemblies into memory. At the lowest level, it boils down to parsing JSON files 😄 but here's what it looks like (and is subject to change):

https://github.com/aspnet/dnx/blob/dev/src/Microsoft.Framework.Runtime.Abstractions/ILibraryManager.cs#L18
https://github.com/aspnet/dnx/blob/dev/src/Microsoft.Framework.Runtime.Abstractions/ILibraryManager.cs#L22

Here's how we use it in MVC:

https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Core/DefaultAssemblyProvider.cs#L44

This API does make the assumption that the entire closure of loadable things ends up in the JSON file or is discovered on the startup path. Anything outside of that can be manually added (scanning directories for dlls and reading them using the new metadata reader API).

[DmitrySikorsky]

Thank you David, Matthew!

[wardbell]

If I understand correctly, we are invited to rethink our discovery pattern.

Where we might once have filtered for assemblies with _classes_ that implemented a particular _interface, now we should consider filtering for libraries that depend upon a particular _library.

This is an auspicious approach even if it isn't exactly the same thing. We don't get the pinpoint targeting that assembly inspection affords. But it's great virtue is that assemblies don't have to be loaded.

The main burden is to structure the libraries so that they filter effectively - yet another reason to make small, focused libraries.

[DmitrySikorsky]

My problem (or task) is how to create modular website using asp.net 5. In the previous version (.NET 4.5) I used MEF for this. I had the main project (web application, container), which had Extensions folder. Inside that folder I could have any number of subfolder. One by extension. Each extension could have frontend and backend areas, views, dlls etc. Also, each extension could provide number of for example db implementations. To use concrete one you had to copy dll to the extension's Configuration file. So it was possible to add functions to the working web application without restarting and any configuration. Every extension provided implementation of IExtension interface which had all information about it (for example, backend menu structure). This is very common task and solution.

Now all of this is useless.

In order to use asp.net 5 with dnx core I'm facing the same problem, but I think that the solution should be different. Now we have dynamic compilation, now we publish source code to the server, now we can have project as dependency. So this question was the part of research and meditation. I don't know what to do with the views for now for example. How to have view in different projects etc etc etc

[davidfowl]

All of that can still work, you just have to know how to do it. For that particular feature (dropping DLLs into a folder and having them be loadable in the app domain), you can look at this sample:

https://github.com/aspnet/Entropy/blob/dev/samples/Runtime.CustomLoader/Program.cs

As for views/areas etc, you need to look at MVC's new extensibility points. I'd head over to the MVC repository for more ideas there.

[resnyanskiy]

I think that links to related SO question and Dmitry repository should be here

• SO - Modular functionality with ASP.NET vNext Core CLR
• Sample project from Dmitry - AspNet5ModularApp

[DmitrySikorsky]

In this case I have one more sample (much bigger one):
https://github.com/Platformus/Platformus

It is platform for other modular projects.

[NickCraver]

Have the suggestions changed here? I'm porting a library to 5.4 and Microsoft.Dnx.Runtime 1.0.0-rc1-final isn't compatible there - it's dnxcore specific, not the new monikers, supporting that most of the functionality there is around Dnx specifics.

For the library loaded I need something that works across all of the netstandard platforms - is that planned? The specific library is StackExchange.Exceptional - our error logger which will run a great many places. The goal is to load other packages as valid error stores simply by including the package. e.g. if you also added StackExchange.Exceptional.MySQL to your project, that store is ready to use...and the core library knows nothing about it, it only contains the base classes the extension implements and is calling those members.

[henkmollema]

@NickCraver the functionality was separated from DNX: https://github.com/aspnet/PlatformAbstractions (also on NuGet).

[NickCraver]

Thanks henk - found what I needed there, much appreciated. For others tripping on this later, a verbose example:

var libs = PlatformServices.Default.LibraryManager.GetReferencingLibraries("myLib")
           .SelectMany(info => info.Assemblies)
           .Select(info => Assembly.Load(new AssemblyName(info.Name)));

[resnyanskiy]

I would also recommend to look at DefaultAssemblyProvider from ASP.NET MVC and comments to https://github.com/dotnet/corefx/issues/1784