Using network drives with MEF

Jul 27, 2009 at 5:00 PM

I currently have a solution where I need to load contracts from a network directory.

After I'm executing the container.Compose(batch) method with a DirectoryCatalog object pointing to the network directory, nothing is loaded.

Any suggestions?

Thanks.

Jul 27, 2009 at 5:03 PM

It does work correctly if I change the path to a local one, but doesn't work from a network drive.

Any suggestions on how to fix this or make it work?

Thanks.

Jul 27, 2009 at 5:06 PM

It think you may be dealing with CASPOL issus. The .NET Framework won’t load assemblies on network shares unless the machine has a policy setup trusting that location. Also loading from a  network is generally not preferred as it locks the files. You might try copying them down to your local folder and loading from there.

Glenn

From: Seablade [mailto:notifications@codeplex.com]
Sent: Monday, July 27, 2009 10:03 AM
To: Glenn Block
Subject: Re: Using network drives with MEF [MEF:63655]

From: Seablade

It does work correctly if I change the path to a local one, but doesn't work from a network drive.

Any suggestions on how to fix this or make it work?

Thanks.

Read the full discussion online.

To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)

To start a new discussion for this project, email MEF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Jul 27, 2009 at 5:22 PM

I was afraid it was going to come down to that.
This particular solution lends itself well to having the assemblies located in a network share.

I will pursue other options so that CAS need not be involved.

Thanks.

Jul 27, 2009 at 5:49 PM

Just out of curiosity, is copying down the assemblies to the local bin not a viable option?

Glenn

From: Seablade [mailto:notifications@codeplex.com]
Sent: Monday, July 27, 2009 10:23 AM
To: Glenn Block
Subject: Re: Using network drives with MEF [MEF:63655]

From: Seablade

I was afraid it was going to come down to that.
This particular solution lends itself well to having the assemblies located in a network share.

I will pursue other options so that CAS need not be involved.

Thanks.

Read the full discussion online.

To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)

To start a new discussion for this project, email MEF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Jul 27, 2009 at 6:28 PM

It's going to complicate things somewhat but I'm going to attempt to make it work that way.

I think it should work.

Jul 27, 2009 at 6:33 PM

Cool. Let me know how that works out…

Glenn

From: Seablade [mailto:notifications@codeplex.com]
Sent: Monday, July 27, 2009 11:28 AM
To: Glenn Block
Subject: Re: Using network drives with MEF [MEF:63655]

From: Seablade

It's going to complicate things somewhat but I'm going to attempt to make it work that way.

I think it should work.

Read the full discussion online.

To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)

To start a new discussion for this project, email MEF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Mar 30, 2010 at 3:16 PM

DirectoryCatalog provided by Visual Studio 2010 RC still shows the same problem and excellent SecuredDirectoryCatalog proposed by Bnaya has also the same problem.

I suspect the problem originates from a bug in the .Net Framework, regarding AssemblyName.GetAssemblyName + Assembly.Load static methods not working with UNC names. This bug can be reproduced independantly of MEF and I have issued bug # 545190 on Microsoft Connect under "Visual Studio and .NET Framework" connection.

Note: In my case, to work around around the problem, I replaced this:
DirectoryCatalog catalog = new DirectoryCatalog(ProgramFolder, "MEF-*.dll");

with this:
AggregateCatalog catalog = new AggregateCatalog();
foreach (string file in Directory.GetFiles(ProgramFolder, "MEF-*.dll"))
{
 Assembly asm = Assembly.LoadFrom(file);
 catalog.Catalogs.Add(new AssemblyCatalog(asm));
}

which works perfectly with a UNC name (just don't forget to add <runtime><loadFromRemoteSources enabled="true"/></runtime> element in Application Configuration File)

Developer
Mar 31, 2010 at 3:57 PM

While Assembly.LoadFrom might meet your needs I would advise that you read about the potential issues at http://msdn.microsoft.com/en-us/library/dd153782.aspx. 

Sep 30, 2010 at 5:14 PM
Edited Sep 30, 2010 at 5:16 PM
Seablade wrote:

It does work correctly if I change the path to a local one, but doesn't work from a network drive.

Any suggestions on how to fix this or make it work?

Thanks.

This would be my suggestion:

 

using System.ComponentModel.Composition.Hosting;
using System.IO;
using System.Linq;
using System.Reflection;

namespace My_MEFSupport
	{
	public class My_AssemblyCatalog : AssemblyCatalog
		{
		public My_AssemblyCatalog(string FileFullName)
			: base(Assembly.Load(File.ReadAllBytes(FileFullName)))
			{ }
		public My_AssemblyCatalog(FileInfo F)
			: this(F.FullName)
			{ }
		}
	public class My_DirectoryCatalog : AggregateCatalog
		{
		public My_DirectoryCatalog(string DirectoryFullName)
			: this(DirectoryFullName,"*.dll")
			{ }
		public My_DirectoryCatalog(string DirectoryFullName,string Pattern)
			: this(Directory.GetFiles(DirectoryFullName,Pattern,SearchOption.TopDirectoryOnly))
			{ }
		public My_DirectoryCatalog(string[] Files)
			: base(Files.Select(i => new My_AssemblyCatalog(i)))
			{ }
		}
	}

Has the added advantage that there will be no locking issues.

 

Sep 30, 2010 at 6:06 PM

Assembly.Load(byte[]) uses a different loading context than .Load, so be mindfull about the implications of using it.

Oct 1, 2010 at 12:44 PM

Sorry, what implications would that be? I've had a look at the documentation and can't find anything apart from the fact that I can go around all of that location based security stuff and the locking. These two implications are intended.

Are there any other implications that I am missing?

Also, with caspol being dead, what would be the alternative?

Copying all assemblies locally would lead to all sorts of concurrency and maintenance issues.

Lots of Greetings!

Volker

Oct 1, 2010 at 6:02 PM

Check this: http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx

Oct 4, 2010 at 2:15 PM

Hi!

Ok, I read it. However, I don't really understand it. It says, Dependencies are loaded from tjhe load context (which doesn't exist) or from the assemblyresolve event. However, Assemblies like System or Microsoft.CSharp are fund without problems.

So, does that mean, if an assembly loaded with Load(Byte[]) will still have its GAC dependencies resolved? It looks that way.

The other thing I found out was that assemblies can get loaded twice. This could indeed be a problem.

I'm not sure yet, how to solve this, except by careful programming (either reference or MEF, never both).

Maybe I'll do some sort of caching mechanism.

Sep 20, 2013 at 12:04 PM
Hi!

I had the same issue and added in the app.config the following code:
  <runtime>
    <loadFromRemoteSources enabled="true"/>
  </runtime>
Things are working fine when accessing a Mapped networked place (e.g. x:\MyPluggins).
However, it fails when I specify the full path (e.g. \MyServer\MyPluggins) and I can't find why.