I am trying to develop a plugin architecture in .Net. The application will be a .Net application. There will be directories which holds the plug-ins. Each directory will represent a plugin. Each plugin directory will also contain all the dependency dlls as well. The plugins need to be stored in separate AppDomain as the plugins may use the same assemblies, but different versions.
As it iterates through the foreach loop in Init(), I get a
System.IO.FileNotFoundException : Could not load file or assembly '[Assembly Name], Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
in _apDomain.Load() for assemblies that are not in the main project.
Code:
readonly private AppDomain _appDomain;
internal ItemModuleAppDomain()
{
AppDomainSetup info = AppDomain.CurrentDomain.SetupInformation;
_appDomain = AppDomain.CreateDomain("ChildDomain");
}
public void Init(string dllDir)
{
string[] dlls = Directory.GetFiles(dllDir, "*.dll", SearchOption.TopDirectoryOnly);
foreach(string dll in dlls)
{
_appDomain.Load(AssemblyName.GetAssemblyName(dll));
}
Any idea why? I tried several methods such as reading the assembly as an array of bytes to load.
I believe AppDomain.Load may be a wrong method for your purpose - it loads the assembly into both current app domain as well as target domain. And you get an error because your assembly is located in a sub folder and .NET does not know about it. You have to give private paths in configuration (http://msdn.microsoft.com/en-us/library/15hyw9x3.aspx). You can also use AssemblyResolve or TypeResolve event of AppDomain for resolution.
You should also look at AppDomain.CreateInstanceFrom method to load your main plugin type (and containing assembly).
Related
I am working on a plug-in based framework that allows plug-ins to exchange data between one another based on some contract (interface).
Currently, a Windows Service can load the plug-ins in two ways:
In the same AppDomain as the Windows Service hosting the plug-ins
In another process that the Windows service communicates with via named pipes (WCF).
This works nicely most of the time. However, there are certain scenarios where one plug-in might reference an assembly, and another plug-in references a newer version of the assembly. In this scenario, I always want the newer version of the dependency to be loaded regardless of which plug-in is loaded first.
Here is the folder structure:
Windows Service Directory (AppDomainBase)
Plugins
Plugin1
Plugin1.dll
SharedDependency.dll (1.0.0.0)
Plugin2
Plugin2.dll
SharedDependency.dll (1.0.1.0)
I have done a lot of research already, and tried many different things. That said:
I cannot redirect assembly bindings via an app.config file. Although this works, it is not practical because I do not know all of the dependencies ahead of time and cannot add every single one to the app.config.
I can't use the GAC
I don't want multiple versions of the same assembly loaded, just the newest one.
I have read about Assembly.Load, LoadFrom, and LoadFile and have tried using all of them. I am still not 100% clear on the difference between Load and LoadFrom. They both seem to automatically load each plug-in's dependencies through fusion and probing from the directory where they are loaded.
My current solution is to search all sub-directories of the AppDomainBase to find and cache all of the DLLs in each plug-in's folder. If I encounter the same assembly more than once, I always keep track of the newest version and its location.
Then, I load each plug-in by calling Assembly.LoadFile so that no dependencies are loaded by fusion. I am subscribing to the AppDomain.CurrentDomain.AssemblyResolve event. When that event is raised, I inspect the Name of the assembly to determine which assembly should be loaded that was pre-cached, and then I load it by calling Assembly.Load.
private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
try
{
Log(string.Format("Resolving: {0}", args.Name));
// Determine if the assembly is already loaded in the AppDomain. Only the name of the assembly is compared here.
var asm = AppDomain.CurrentDomain.GetAssemblies().FirstOrDefault(a => a.GetName().FullName.Split(',')[0] == args.Name.Split(',')[0]);
if (asm == null)
{
// The requsted assembly is not loaded in the current AppDomain
Log(string.Format("Assembly is not loaded in AppDomain: [{0}]", args.Name));
// Determine if the assembly is one that has already been found and cached
var asmName = _RefCandidates.Find(a => a.Name.FullName.Split(',')[0] == args.Name.Split(',')[0]);
if (asmName != null)
{
// The assembly exists in the cache, but has not been loaded. Load it.
Log(string.Format("Pre-loaded assembly found in cache. Loading: [{0}], [{1}]", asmName.Name, asmName.Name.CodeBase));
return Assembly.LoadFile(asmName.File.FullName);
}
}
else
Log(string.Format("Assembly is already loaded in AppDomain: [{0}], [{1}]", asm.GetName(), asm.GetName().CodeBase));
return asm;
}
catch (Exception ex)
{
Logger.Write(ex, LogEntryType.Error);
return null;
}
}
First of all, what is the best way to accomplish what I need to do, and what am I doing wrong?
Second, what happens if a dependency in the chain is expecting to reference something that is in the GAC? I assume it will no longer be found since I am using LoadFile and skipping fusion all together. Also, I have read some things about serialization not working with LoadFile. What specifically? How about resource assemblies?
This model is assuming that all newer versions of dependent assemblies are backward compatible since I'll be loading only the newest version.
Any input is greatly appreciated.
You can't load assembly manually, if the resolution of this assembly not fails(only in this case AssemblyResolve is raised).
So, your plugin architecture can not be implemented with Assembly.Load* methods.
There are two paths now.
First(not recommended): somehow remove the restriction(for example use Assembly.Load at start, and in any point you need an object, search for CurrentDomain assemblies, pick right assembly and by reflection construct objects and use them).
Second(recommended): review your initial problem and search for solution, that can be simple to implement and maintain.
Take a look, what Managed Extensibility Framework offers for plugin architecture.
SharpDevelop folks wrote a book, telling us about their plugins tree.
Find your way.
Also see this link about assembly loading context to understand why Assembly.Load without AssemblyResolve event will not work.
I have a problem with MEF and using a plugins folder.
I have a main app that supports plugins via MEF. The main app does not reference the assemblies containing the .NET Task type for multithreading but one or more of the plugins do.
The plugins are located in a Plugins folder and I'm using a DirectoryCatalog.
I keep getting ReflectionTypeLoadException being thrown by MEF on
Unable to load one or more of the requested types. Retrieve the
LoaderExceptions property for more information.
The LoaderExceptions property contains a FileNotFoundException
"Could not load file or assembly 'System.Threading.Tasks,
Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file
specified.":"System.Threading.Tasks, Version=1.5.11.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
The plugin is referencing System.Threading.Tasks via a Microsoft NuGet package reference.
This is my helper method:
public static void Compose(IEnumerable<string> searchFolders, params object[] parts)
{
// setup composition container
var catalog = new AggregateCatalog();
// check if folders were specified
if (searchFolders != null)
{
// add search folders
foreach (var folder in searchFolders.Where(System.IO.Directory.Exists))
{
catalog.Catalogs.Add(new DirectoryCatalog(folder, "*.dll"));
}
}
catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));
// compose and create plug ins
var composer = new CompositionContainer(catalog);
composer.ComposeParts(parts);
}
public class MEFComposer
{
[ImportMany(typeof(IRepository))]
public List<IRepository> Repositories;
[ImportMany(typeof(ILogging))]
public List<ILogging> LoggingRepositories;
[ImportMany(typeof(IPlugin))]
public List<IPlugin> Plugins;
}
This is the code I'm using to invoke MEF and load the plugins.
public void Compose()
{
// try to connect with MEF types
try
{
var parts = new MEFComposer();
MEFHelpers.Compose(new[] { Path.Combine(Application.StartupPath, "Plugins") }, parts);
RepositoryFactory.Instance.Repository = parts.Repositories.FirstOrDefault();
Logging.Repositories.AddRange(parts.LoggingRepositories);
foreach (var plugin in parts.Plugins)
{
this.applicationApi.Plugins.Add(plugin);
plugin.Connect(this.applicationApi);
}
}
catch
{
// ERR: handle error
}
}
Why is MEF not able to load the plugins even though the Microsoft.Threading.Tasks.dll and related assembly files are present in the Plugins folder, but not the main application bin folder? And is there any way of telling MEF to search the Plugins folder for assembly dependencies?
Having a plugin model means I can't anticipate what assemblies a plugin may be referencing so I cannot include them in the main bin folder for the app, which is why I want all related plugins and plugins dependencies to be in the plugins folder.
You have run into an essential problem when supporting 3rd party plugins. Your problem is that when you are loading the plugin, the runtime will search for its references when needed only in the specified folders your AppDomain knowns of. That would be the WorkingDirectory of that process, then path etc.
Essentially, you are loading an Plugin that requires System.Threading.Tasks. That DLL lies within your /Plugin folder. As .net loads your plugin, it will search for that assembly but has no way in finding it as it is located within the /Plugin folder and fails.
There are a couple of solutions to that.
Do not use a Plugin folder
That would be the most simple solution, when all assemblies (including references of the 3rd party lib) are located in your WorkingDirectory, .net will have not trouble finding all references of that plugin.
Add the Plugin folder to your Probing path
This will extend the paths .net will search the 3rd party references:
https://learn.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies#locating-the-assembly-through-probing
Use AppDomains for each plugin.
An AppDomain is my choice of go here as it allows you to load the assembly not only in its "own" container, but also can simulate the Working directory only for the plugin. That can come handy if on of the Plugins uses the same framework as your application but in a different version for example.
Load the dependencies by yourself
That would be the "straight forward" method of solving this. You can load every assembly as ReflectionOnly, Determinate all dependencies and then load these. That will almost Garantie to work.
4.1. AssemblyResolve event
This is just another way how to "redirect" .net to load assemblies from the PluginFolder
https://learn.microsoft.com/en-us/dotnet/api/system.appdomain.assemblyresolve?view=netframework-4.8
Edit:
There is also a certain problem with the AssemblyCatalog, it uses Assembly.Load instead of Assembly.LoadFrom to load the given assembly. That is an essential part of your problem, as LoadFrom would probe the path where the assembly originates from for its dependencies where Load does not.
https://github.com/JPVenson/MSEF/blob/master/JPB.Shell/JPB.Shell.MEF/Model/StrongNameCatalog.cs
You could use an Catalog like this one that is using LoadFrom instead.
Disclaimer: I am the creator of that project.
There are several questions out there that ask the same question. However the answers they received I cannot understand. Similar questions:
Dynamically Load Assembly and manually force path to get referenced assemblies ;
Loading assemblies and its dependencies
The question in short:
I need to figure out how dependencies, ie References in my modules can be loaded dynamically. Right now I am getting "The system cannot find the file specified" on Assemblies referenced in my so called modules.
I cannot really understand how to use the AssemblyResolve event.
The longer version
I have one application, MODULECONTROLLER, that loads separate modules.
These "separate modules" are located in well-known subdirectories, like
appBinDir\Modules\Module1
appBinDir\Modules\Module2
Each directory contains all the DLLs that exists in the bin-directory of those projects after a build.
So the MODULECONTROLLER loads all the DLLs contained in those folders using this code:
byte[] bytes = File.ReadAllBytes(dllFileFullPath);
Assembly assembly = null;
assembly = Assembly.Load(bytes);
I am, as you can see, loading the byte[]-array (so I don't lock the DLL-files).
Now, in for example MODULE1, I have a static reference called MyGreatXmlProtocol. The MyGreatXmlProtocol.dll then also exists in the directory appBinDir\Modules\Module1 and is loaded using the above code
When code in the MODULE1 tries to use this MyGreatXmlProtocol, I get:
Could not load file or assembly 'MyGreatXmlProtocol, Version=1.0.3797.26527, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
So, in a post (like this one) they say that
To my understanding reflection will
load the main assembly and then search
the GAC for the referenced assemblies,
if it cannot find it there, you can
then incorparate an assemblyResolve
event:
First; is it really needed to use the AssemblyResolve-event to make this work? Shouldn't my different MODULEs themself load their DLLs, as they are statically referenced?
Second; if AssemblyResolve is the way to go - how do I use it? I have attached a handler to the Event but I never get anything on MyGreatXmlProctol.
Edit
Code regarding the AssemblyResolve-event handler:
public GUI()
{
InitializeComponent();
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
...
}
//
Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
Console.WriteLine(args.Name);
return null;
}
try to do assembly = Assembly.Load(bytes); to MyGreatXmlProtocol assembly. I read somewhere that if you load assembly by byte array you have to resolve dependencies manually.
I have an Assembly Library1.dll which contains some Interfaces, which were serialized as a byte array into the database. For some reasons we have to change the Interface properties and defintion. so now i am writing a migration utility. So i have 2 versions of Library1.dll , In my utility i have created a folder where i store the new version of Library1.dll . This utility in turn also references Library1.dll hence in bin folder contains Library1.dll but this dll is compiled on older version. My new version of Library1.dll is stored in a private path which i am passing to Assembly.ReflectionOnlyLoadFrom function to instantiate and hence GetTypes on the assembly loaded which further would enable me to do conversion of data.
But I always get ReflectionTypeLoadException when trying to load Library1.dll from private path.
Please help guys!!!. any help would be appreciated. I am really stuck.
Thanks,
AG
If your Library is referencing another dll, GetTypes will fail when it hits a type that uses an external type. Unlike normal assembly loading, ReflectionOnly Assembly loading will not resolve dependencies. You can either subscribe to AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve and load the dependencies as required, or you could pre-load them.
This is the code I use for this:
var assembly = Assembly.ReflectionOnlyLoadFrom(assemblyPath);
foreach (var assemblyName in assembly.GetReferencedAssemblies()) {
try {
Assembly.ReflectionOnlyLoad(assemblyName.FullName);
} catch {
Assembly.ReflectionOnlyLoadFrom(Path.Combine(Path.GetDirectoryName(assemblyPath), assemblyName.Name + ".dll"));
}
}
This will try to load all dependencies of the reflection-only loaded assembly first by fullname, then by path (assuming that the dependency is in the same directory as the loaded assembly).
I have created a windows service in C# VS2008 that uses a reference to an external class library to wrote. I have added the reference to it in VS2008. When I run start the service it throws an exception when trying to access the external DLL:
Could not load file or assembly 'vcribAPI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
The DLL is in the same directory as the service.exe file. Is there something special that I need to do for windows services like putting the DLL in another directory?
It could be that vcribAPI.dll relies on other assemblies as well. I suggest using Reflector and open up the dll to see what other dll's it might reference.
I encountered exactly the same error.
The working directory of services is different from the application directory (typically C:\Windows\System32).
For example, the method AssemblyName.GetAssemblyName throws a FileNotFoundException if you try to locate an assembly deployed in the application directory.
In this case, the solution is to define Environment.CurrentDirectory with the application directory before assembly loading.
Sample code :
const string SCHEMA_FILE = #"file:\";
var appAssembly = Assembly.GetExecutingAssembly();
var path = Path.GetDirectoryName(appAssembly.CodeBase);
if (path.StartsWith(SCHEMA_FILE))
path = path.Remove(0, SCHEMA_FILE.Length);
Environment.CurrentDirectory = path;
Does you service have rights to read in the folder?
Does the assembly have other dlls or assemblies it depends on?
If so, they also need to be in this directory.
To be certain, start up the Assembly Loader Log (fusion log). See this howto (Debugging Assembly Loading Failures).