One day I'm writing some reflection code to iterate through all the assembly to find a specific interface and then call a method on it in Startup. It seems that this function seems simple, but in reality, there is no clear, simple, suitable for various situations to obtain an assembly. This article is very boring for some people, but if I can help even one person solve such problems, then this article is worth it.
Seriously, since there are multiple ways to get assembly, I will not say "using this method". It's very likely that there may be only one way to work for your specific project, so relying on other ways is meaningless. Let's simply test all the methods and see which method is the most reasonable.
use
The first option you may encounter is. It (seems) loads all the assembly in AppDomain, basically every assembly that your project uses. But there are a lot of warnings. In .NET, assemblies are loaded into AppDomain. It cannot load all assembly at once. Instead, it will only load it when you call a method/class in an assembly - that is, load it on the fly. This is reasonable because if you never use an assembly, there is no reason to load it.
But the problem is that at the point in time when you call(), if you do not call a method of a specific assembly, it will not be loaded. Now if you want to get all the assembly for the Startup method, it is very likely that you have not called that assembly yet, which means it has not loaded into AppDomain, so you cannot get this interface method.
In terms of code:
(); // Does not return SomeAssembly as it hasn't been called yet. (); (); // Will now return SomeAssembly.
While this may seem like an attractive option, know that timing is everything for this approach.
Use AssemblyLoad Event
Because you can't make sure that when you call() all assembly is loaded, and actually an event will run when AppDomain loads another assembly. Basically, you can be notified when an assembly is delayed. It looks like this:
+= (sender, args) =>
{
var assembly = ;
};If you just want to check something when the assembly is loading, this might be a good solution, but this process doesn't necessarily happen at a certain point (it doesn't happen in your .NET Core app class).
Another problem with this method is that by the moment you add your event handler, there is no guarantee that the assembly has not been loaded yet (in fact, they are likely to have been loaded). so what? You need to put in double effort, first add your event processor, then quickly check to find something that has been loaded.
This is a perfect solution, but this won't work if you're used to using lazy loading assemblies to do things.
Use GetReferencedAssemblies()
The next in the ranking is GetReferencedAssemblies(). Essentially, you can get all referenced assembly through an assembly, such as your entry point assembly, generally your web project.
The code itself looks like this:
().GetReferencedAssemblies();
Again, it seems like a trick, but this method has another big problem. There will be a concept of "pattern separation" in many projects, such as Web Project>>Service Project>>Data Project. The Web Project itself does not directly refer to the Data Project. And when you call "GetReferencedAssemblies" it means direct reference. So if you expect to get Data Project in the assembly list, you will be disappointed.
So, again, it works fine in some cases, but not a universal solution.
Loop GetReferencedAssemblies()
Another option to use GetReferencedAssemblies() is to create a method to iterate through all assembly. Similar to this:
public static List GetAssemblies()
{
var returnAssemblies = new List();
var loadedAssemblies = new HashSet();
var assembliesToCheck = new Queue();
(());
while(())
{
var assemblyToCheck = ();
foreach(var reference in ())
{
if(!())
{
var assembly = (reference);
(assembly);
();
(assembly);
}
}
}
return returnAssemblies;
}The boundaries of this method are a bit rough, but it does work and means that in the Startup method you can see all the assembly immediately.
The one time you might get stuck with this method is if you are loading the assembly dynamically and they are not actually referenced by any project. For this case, you need the next method.
Directory DLL loading
A very rough way to get all the solutions dlls is to load them out of your bin folder. It looks like this:
public static Assembly[] GetSolutionAssemblies()
{
var assemblies = (, "*.dll")
.Select(x => ((x)));
return ();
}It works fine but it is indeed a rough solution. But one of the biggest benefits of using this method is that a dll needs to be simply placed in the directory that needs to be loaded. So if you load DLLs dynamically for any reason, for you, this is probably the only way (except for listening to AssemblyLoad in AppDomain).
This is one of the ways to do this thing that looks like a prank. But it's very likely that you've been blocked into the corner and that's the only way to solve the problem.
Just get "My" assembly
Using any of these methods, you will soon find that you are loading each assembly under Nuget into your project, including Nuget packages, .NET core libraries, and even runtime specific dlls. In the .NET world, an assembly is an assembly. There is no "yes, but this is my assembly" and they are very special.
The only way to filter is to check the name. You can do it as a whitelist, so if all the items in the solution start with "MySolution". So you can filter like this:
().GetReferencedAssemblies().Where(x => ("MySolution."))Or you can choose a blacklist option that doesn't really limit your assembly, but at least reduces the number of assembly you are loading/checking/processing. Like this:
().GetReferencedAssemblies()
.Where(x => !("Microsoft.") && !("System."))Blacklists may look stupid, but in some cases, if you are building a library that doesn't actually know the name of the final solution, then this is the only way to reduce what you're trying to load.
This is the end of this article about how to obtain assembly in C#. For more related C# to obtain assembly content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!