I work with MEF and I am looking how to change the url of the location of plugins by another means that MEF find the plugins, I want to change this line
Assembly.LoadFrom(#"C:\julia\project\project.Plugin.Nav\bin\Debug\NavPlugin.dll")));
I want to delete this url because I need to deploy my application in another machine
This is my function :
public void AssembleCalculatorComponents()
{
try
{
//var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
//var container = new CompositionContainer(catalog);
//container.ComposeParts(this);
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(Assembly.LoadFrom(#"C:\yosra\project\project.Plugin.Nav\bin\Debug\NavPlugin.dll")));
var container = new CompositionContainer(catalog);
container.ComposeParts(this);
}
catch (Exception ex)
{
throw ex;
}
}
Can you please help me?
Thanks
You can use the DirectoryCatalog class to have MEF scan a particular directory for assemblies that satisfy your imports.
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog("."));
var container = new CompositionContainer(catalog);
The above will add the base directory the AppDomain uses for locating assemblies (usually the directory holding the executable unless changed with configuration) to the aggregate catalog. You will also probably want to add the current executing assembly, though it is not required.
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
catalog.Catalogs.Add(new DirectoryCatalog("."));
var container = new CompositionContainer(catalog);
More information on MSDN for DirectoryCatalog: http://msdn.microsoft.com/en-us/library/system.componentmodel.composition.hosting.directorycatalog.aspx
Hello again and thanks for your response, so my problem was to load the plugin directly, so i create a directory and i place my plugins in this folder, so i find this solution
public void AssembleCalculatorComponents()
{
string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Plugins");
Console.WriteLine(path);
//Check the directory exists
if (!Directory.Exists(path))
{
Directory.CreateDirectory(path);
}
Console.WriteLine(path);
string assemblyName = Assembly.GetEntryAssembly().FullName;
Console.WriteLine(assemblyName);
//Create an assembly catalog of the assemblies with exports
var catalog = new AggregateCatalog(
new AssemblyCatalog(Assembly.GetExecutingAssembly().Location),
new AssemblyCatalog(Assembly.Load(assemblyName)),
new DirectoryCatalog(path, "*.dll"));
//Create a composition container
var container = new CompositionContainer(catalog);
container.ComposeParts(this);
this is my solution , thinks for all
Two options.
Use the current directory as the root for your plugins. Environment.CurrentDirectory should point you in the right direction.
Use an app.config to specify a directory for your plugins to be stored in.
If your method knows of the type to be instantiated, you can use the Assembly property of the Type which is typical for my *Domain* libraries; otherwise, you can use Assembly.GetExecutingAssembly(). I am not particularly fond of GetExecutingAssembly() or GetCallingAssembly() ...:
public void AssembleCalculatorComponents() {
try {
var asmCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
// OR
asmCatalog = new AssemblyCatalog(typeof(TObject).Assembly); // replace TObject with object's actual type
var aggregateCatalog = new AggregateCatalog(asmCatalog);
//
AddDirectoryCatalogs(aggregateCatalog.Catalogs));
var container = new CompositionContainer(catalog);
// assuming this class has the member(s) to be composed.
container.ComposeParts(this);
} catch (Exception ex) {
throw ex;
}
}
Aside from that, you can add DirectoryCatalogs - either by the app.config file, serialized list of directories, etc. Starting off, though, you can designate a default directory in your app.config - which is what I recommend. Then, assuming you are using Settings:
private readonly Settings settings = Settings.Default;
void AddDirectoryCatalogs(ICollection<ComposablePartCatalog> Catalogs agrCatalogs ) {
agrCatalogs.Add(new DirectoryCatalog(settings.DefaultPath, settings.DefaultPattern));
// add more directory catalogs
}
While using "." as the search path is a legitimate shortcut to the executing assembly's directory, keep in mind that all assemblies will be searched for fulfilling parts - i.e., matching Import/Export objects. Use of specific patterns is my recommendation. Microsoft's examples are not known for being the best practices. If you expect any plugin to be suffixed with Plugin.dll, make that part of your search pattern.
Related
I am trying to make a small C# tool to compare two svn revision builds and track properties changes in any classes. My goal is to use reflection to compare the properties of each class of my dll without using Momo.Cecil.
From experimenting, then reading this article Assembly Loading and a few threads found on Google, I learnt that two DLLs with same identities would get resolved as the same if we dont use Assembly.ReflectionOnlyLoadFrom.
Trying to use their code to create an AppDomain for each loading, and also try many variants from searches, I get this exception and I can't find any thread explaining how to solve this issue:
API restriction: The assembly 'file:///D:\somepath\82\MyLib.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.
This error happen on the 2nd call (the path 82) on the following line:
Assembly assembly = Assembly.ReflectionOnlyLoadFrom(assemblyPath);
Maybe I din't understand something very basic which make me unable to create a new AppDomain correctly?
Here is all the code used to reproduce this problem.
Code from my entry point
//Let say one of the property has been renamed between both commits
var svnRev81Assembly = ReflectionOnlyLoadFrom(#"D:\somepath\81\MyLib.dll");
var svnRev82Assembly = ReflectionOnlyLoadFrom(#"D:\somepath\82\MyLib.dll");
Implementation of the loader
private string _CurrentAssemblyKey;
private Assembly ReflectionOnlyLoadFrom(string assemblyPath)
{
var path = Path.GetDirectoryName(assemblyPath);
// Create application domain setup information.
AppDomainSetup domaininfo = new AppDomainSetup();
domaininfo.ApplicationBase = path;
domaininfo.PrivateBinPath = path;
_CurrentAssemblyKey = Guid.NewGuid().ToString();
AppDomain currentAd = AppDomain.CreateDomain(_CurrentAssemblyKey, null, domaininfo); //Everytime we create a new domain with a new name
//currentAd.ReflectionOnlyAssemblyResolve += CustomReflectionOnlyResolver; This doesnt work anymore since I added AppDomainSetup
currentAd.SetData(_CurrentAssemblyKey, path);
//Loading to specific location - folder 81 or 82
Assembly assembly = Assembly.ReflectionOnlyLoadFrom(assemblyPath);
//Preloading the
foreach (var assemblyName in assembly.GetReferencedAssemblies())
{
Assembly.ReflectionOnlyLoadFrom(Path.Combine(path, assemblyName.Name + ".dll"));
}
Type[] types = assembly.GetTypes();
// Lastly, reset the ALS entry and remove our handler
currentAd.SetData(_CurrentAssemblyKey, null);
//currentAd.ReflectionOnlyAssemblyResolve -= CustomReflectionOnlyResolver; This doesnt work anymore since I added AppDomainSetup
return assembly;
}
This can solved by loading dlls in seperate appdomain.
private static void ReflectionOnlyLoadFrom()
{
var appDomain = AppDomain.CreateDomain("Temporary");
var loader1 = (Loader)appDomain.CreateInstanceAndUnwrap(typeof(Loader).Assembly.FullName, typeof(Loader).FullName);
loader1.Execute(#"D:\somepath\81\MyLib.dll");
var loader2 = (Loader)appDomain.CreateInstanceAndUnwrap(typeof(Loader).Assembly.FullName, typeof(Loader).FullName);
loader2.Execute(#"D:\somepath\82\MyLib.dll");
loader1.CompareTwoDLLs(loader2);
AppDomain.Unload(appDomain);
}
Loader.cs
public class Loader : MarshalByRefObject
{
public Assembly TempAssembly { get; set; }
public string Execute(string dllPath)
{
TempAssembly = Assembly.LoadFile(dllPath);
return TempAssembly.FullName;
}
public void GetRefAssemblyTypes()
{
foreach (var refAssembly in TempAssembly.GetReferencedAssemblies())
{
var asm = Assembly.Load(refAssembly);
var asmTypes = asm.GetTypes();
}
}
public void CompareTwoDLLs(Loader l2)
{
var types1 = TempAssembly.GetTypes();
var types2= l2.TempAssembly.GetTypes();
GetRefAssemblyTypes();
//logic to return comparison result
}
}
I need to develop a Shell Context Menu extension that references some other custom assemblies... I don't want to assign a Strong Name Key to those custom assemblies!
The guide I followed to do this uses the SharpShell project and illustrates how to sign (but does not expalins why) the assembly... and this is my problem: if I sign my final .dll then I have many errors during my project's building phase, because some assemblies my project references are not strongly named ("Referenced assembly does not have a strong name").
In general, googling about the C# Shell Extension implementation, all best tutorials I found sign the final assembly... is it mandatory?
Without signing the assembly ServerManager.exe returns this error: "The file 'XYZ.dll' is not a SharpShell Server".
Finally I've solved my troubles... the SharpShell.dll file obtained through NuGet was a different version of the ServerManager.exe ones.
Uninstalling the SharpShell NuGet package and directly referencing the SharpShell.dll you find inside the ServerManager folder was my solution!
Moreover, I was looking between the article comments... please read this question.
You don't need to use old DLL.
Please use this code directly, without using ServerManager.exe.
private static ServerEntry serverEntry = null;
public static ServerEntry SelectedServerEntry
{
get
{
if (serverEntry == null)
serverEntry = ServerManagerApi.LoadServer("xxx.dll");
return serverEntry;
}
}
public static ServerEntry LoadServer(string path)
{
try
{
// Create a server entry for the server.
var serverEntry = new ServerEntry();
// Set the data.
serverEntry.ServerName = Path.GetFileNameWithoutExtension(path);
serverEntry.ServerPath = path;
// Create an assembly catalog for the assembly and a container from it.
var catalog = new AssemblyCatalog(Path.GetFullPath(path));
var container = new CompositionContainer(catalog);
// Get the exported server.
var server = container.GetExport<ISharpShellServer>().Value;
serverEntry.ServerType = server.ServerType;
serverEntry.ClassId = server.GetType().GUID;
serverEntry.Server = server;
return serverEntry;
}
catch (Exception)
{
// It's almost certainly not a COM server.
MessageBox.Show("The file '" + Path.GetFileName(path) + "' is not a SharpShell Server.", "Warning");
return null;
}
}
Install code:
ServerRegistrationManager.InstallServer(SelectedServerEntry.Server, RegistrationType.OS64Bit, true);
Register code:
ServerRegistrationManager.RegisterServer(SelectedServerEntry.Server, RegistrationType.OS64Bit);
I am getting my MEF specific dll like this:
string exeFile = (new Uri(Assembly.GetEntryAssembly().CodeBase)).AbsolutePath;
string exeDir = Path.GetDirectoryName(exeFile);
using (DirectoryCatalog catalog = new DirectoryCatalog(Path.Combine(exeDir,"Custom")))
{
using (CompositionContainer container = new CompositionContainer(catalog))
{
container.ComposeParts(this);
}
}
And this works if I am in development, but if I build and take the build output and put it in a folder called c:\test 1, when I run the app from c:\test, it says it can't find the c:\test 1\custom directory.
The Custom folder in the same path as the EXE
I noticed, it only can't find it if the directoy has a space in it like test 1, but it does work fine if it is just test1
If I run it with a space, I get the error:
Could not find part of the path 'C:\TEST%202\CUSTOM\'.
Uri.UnescapeDataString worked?
I used as follows:
using (DirectoryCatalog catalog = new DirectoryCatalog(Uri.UnescapeDataString(path)))...
Try this:
string exeFile = Assembly.GetEntryAssembly().Location;
string exeDir = Path.GetDirectoryName(exeFile);
string path = Path.Combine(exeDir, "Custom");
using (DirectoryCatalog catalog = new DirectoryCatalog(path))
{
using (CompositionContainer container = new CompositionContainer(catalog))
{
container.ComposeParts(this);
}
}
You should use Location instead of CodeBase (msdn).
MSDN Remarks:
To get the absolute path to the loaded manifest-containing file, use
the Assembly.Location property instead.
Let's say that I have a few applications in a folder (each application has subfolders where plugins can be located):
Clients
Application A
...
Application B
...
Application C
...
...
Some files in these applications have an Export-attribute applied, others don't. Now, I want to be able to load these plugins in some of these applications. Is there a proper way to let MEF search recursively in every subfolder of a specified folder?
No, you will need to recurse through the directories yourself creating a DirectoryCatalog for each. Then, combine all of the DirectoryCatalogs with an AggregateCatalog to create the container.
Another way is to get all the DLL files under a specified directory (recursively) and load them one by one using the assembly catalog.`
var catalog = new AggregateCatalog();
var files = Directory.GetFiles("Parent Directory", "*.dll", SearchOption.AllDirectories);
foreach (var dllFile in files)
{
try
{
var assembly = Assembly.LoadFile(dllFile);
var assemblyCatalog = new AssemblyCatalog(assembly);
catalog.Catalogs.Add(assemblyCatalog);
}
catch (Exception e)
{
// this happens if the given dll file is not a .NET framework file or corrupted.
}
}
There's a MEFContrib project available that has a RecursiveDirectoryCatalog for just this purpose...
https://www.nuget.org/packages/MefContrib/
I created an implementation based in Nicholas Blumhardt answer, I hope that code helps others in future.
private void RecursivedMefPluginLoader(AggregateCatalog catalog, string path)
{
Queue<string> directories = new Queue<string>();
directories.Enqueue(path);
while (directories.Count > 0)
{
var directory = directories.Dequeue();
//Load plugins in this folder
var directoryCatalog = new DirectoryCatalog(directory);
catalog.Catalogs.Add(directoryCatalog);
//Add subDirectories to the queue
var subDirectories = Directory.GetDirectories(directory);
foreach (string subDirectory in subDirectories)
{
directories.Enqueue(subDirectory);
}
}
}
Here's a small class I'm using to probe for a list of available plugins:
internal static class PluginDirectoryLoader
{
public static PluginInfo[] ListPlugins(string path)
{
var name = Path.GetFileName(path);
var setup = new AppDomainSetup
{
ApplicationBase = path,
ShadowCopyFiles = "true"
};
var appdomain = AppDomain.CreateDomain("PluginDirectoryLoader." + name, null, setup);
var exts = (IServerExtensionDiscovery)appdomain.CreateInstanceAndUnwrap("ServerX.Common", "ServerX.Common.ServerExtensionDiscovery");
PluginInfo[] plugins = null;
try
{
plugins = exts.ListPlugins(); // <-- BREAK HERE
}
catch
{
// to do
}
finally
{
AppDomain.Unload(appdomain);
}
return plugins ?? new PluginInfo[0];
}
}
The path parameter points to a subdirectory containing the plugin assemblies to load. The idea is to load them using a separate AppDomain with shadow copying enabled.
In this case, shadow copying isn't really necessary seeing as the AppDomain is unloaded quickly, but when I actually load the plugins in the next block of code I intend to write, I want to use shadow copying so the binaries can be updated on the fly. I have enabled shadow copying in this class as a test to make sure I'm doing it right.
Apparently I'm not doing it right because when I break in the debugger on the commented line in the code sample (i.e. plugins = exts.ListPlugins()), the original plugin assemblies are locked by the application!
Seeing as I'm specifying that assemblies loaded by the AppDomain should be shadow copied, why are they being locked by the application?
I figured it out. There was one property I missed in AppDomainSetup. The property was ShadowCopyDirectories.
var setup = new AppDomainSetup
{
ApplicationBase = path,
ShadowCopyFiles = "true",
ShadowCopyDirectories = path
};
When breaking on the line mentioned in my question, I can now delete the plugin assemblies even without unloading the AppDomain.