not sure how this code works, the foreach loop should throw an InvalidOperationException, as you modify the collection on the loop...

the problem i can see is that this will load the assembly in your appDomain, maybe you want to create another, so you can unload them after?

also, shouldn't it be a List ? it seens that you're trying to load multiple assemblies from one file...

maybe this method can help in a first attempt to removo possible problematic assemblies:

http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getreferencedassemblies.aspx

using it, you can check if the assembly references your own, then you can check the version it references, if it's lower than the current one, you remove it. this way you'll not have an exception.

at this point i'm just throwing suggestions on the table, but maybe we can get something that works for you, my current understanding is that you're receiving an exception everytime you load an plugin that was compiled with an old version of your main project, that isn't compatible anymore...

this question on StackOverflow has an example use of the method i described:

http://stackoverflow.com/a/2135347

i really couldn't find a way to only skip the assembly if it isn't compatible, as in "if it uses an older version, but is still compatible, load it", all solutions i found are either based on version numbers or in type loader exceptions...

The issue is not that the assembly is missing references, it finds and links them when it is loaded. The issue is that a reference inside both assemblies is a mismatch.

Also yes that code crashes, better fix that quickly.

Also to load into your current domain you do AppDomain.CurrentDomain.Load, not Assembly.LoadFile. LoadFile makes an assembly as an object so you can add it with AppDomain.CurrentDomain.Load, hence why AppDomain.CurrentDomain does not have a LoadFile method.

So it is like it is loading the assembly as a side object then testing if it works. If it does then it will be loaded to an AggregateCatalog for MEF. This also removes the need for the dlls object:

var catalog = new AggregateCatalog();
foreach (var assem in dllNames.Select(Assembly.LoadFile))
{
	try
	{
		assem.GetTypes();
		catalog.Catalogs.Add(new AssemblyCatalog(assem));
	}
	catch (ReflectionTypeLoadException e)
	{
	}
}

Also the issue is that it is wanted that even of the plugin was designed for an older version it will still run, provided there are no reference errors. That way if plugin makers don't need to update they don't have to. It saves time for the plugin maker and for users that don't have to update every plugin with each new release. Hence why excluding based on version numbers can't really tell if there is even an issue.

well, what is strange is that i just tested and it seens like there's no problem if i change the host application as long as i don't change the interfaces used by the plugin... on the case that the interface changes, then there's no way to run the plugin without a recompile... how are you loading your plugins? i tested with the DirectoryCatalog and it worked fine. in the case i change the interface, this is the message i get: {"Method '' in type '' from assembly 'plugin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.":""} it's not the same you're getting, so i supose it happens under another circunstance? anyway, your solution seens to be the only way to do this, as a look into the MEF documentation doesn't reveal anything useful for that... and if the GetTypes method throws an exception, i don't think you can do much more. i'll keep looking and if i found a better solution i'll let you know, your problem may as well be mine, as i'll use MEF on the same way on my next project

I used to use a DirectoryCatalog however it does not allow the type of checking above; In the current project it still uses one actually , I haven't had time to implement any updates. Also the assembly I was using to test had massive differences (method renaming, some properties were removed, explicit implementation of things that don't exist in the interface anymore) between the interfaces, so that is probably why I had a different error.

Also thank you for the help, and I hope your next project does not have as many issues as this one is having.

i'll probably have the same issues

yeah, in the case of massive changes, your solution is the only working one until now, it's a shame that MEF doesn't current have that kind of hook, i'm thinking that i should create my own implementation for it...

the issue is that MS doesn't have a TryLoadFile() or something like that, you can know it does the check as it throws the exception but I can't find a method or construct that can just return if the check was successful.