Catalog for all loaded assemblies

Feb 11, 2009 at 2:41 AM
Perhaps I am overlooking this. Is there a simple way to create a catalog for all loaded assemblies, whatever that may be?

I realize there would be challenges around this, but it seems like it would be very helpful.
Feb 11, 2009 at 3:46 AM
This might be a strange approach, Kathleen, but you might be able to do it with Linq and reflection. This is calling Assembly.Load on all referenced assemblies, so it probably isn't the same thing as "all loaded assemblies", but anyway:

var allAssemblies = new AssemblyCatalog(
Assembly.GetExecutingAssembly().GetReferencedAssemblies()
.Select(n =>
Assembly.Load(n))
.Union(
new[] { Assembly.GetExecutingAssembly() })
);

Matt

Feb 11, 2009 at 7:53 AM
Actually I would recommend a variation of what Matt offered above. Use AppDomain.Current, and from there you should be able to get all assemblies that were loaded using the GetAssemblies() method.

http://msdn.microsoft.com/en-us/library/system.appdomain.getassemblies.aspx
Feb 11, 2009 at 8:09 AM
Oh that's neat. I'll have to remember that one myself!
Feb 11, 2009 at 3:39 PM

Neither of these will pick up assemblies that are bound only by a third contract assembly, e.g.:

Main (exe assembly)

A.Interfaces (shared contracts used by exe)

A.Implementations (implementations of shared contracts)

If Main references A.Interfaces, but the implementations are in A.Implementations, then neither the set of loaded assemblies when executing in Main, nor the reachable assemblies from Main, will include A.Implementations.

DirectoryCatalog might be a better option all-round here.

Nick

From: mabster [mailto:notifications@codeplex.com]
Sent: Wednesday, February 11, 2009 1:09 AM
To: Nicholas Blumhardt
Subject: Re: Catalog for all loaded assemblies [MEF:46797]

From: mabster

Oh that's neat. I'll have to remember that one myself!

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

Feb 11, 2009 at 4:36 PM
Nick,

I see this as kind of a two way thing, and in one direction, yes, directory catalog is good.

So, let's say I have a composable app that uses MEF to start a process. While runnning, this process needs to reach out to the outside environment (environment = code that called it), let's say to grab a peice of information, although logging and progress come to mind as well. I am willing to make the assumption that whatever has the information the process needs is loaded. Sure, it might not be, so maybe a directory search if the export isn't found is a good idea. But before I do a directory search, I want to ensure that nothing in memory supports the export. Does the directory catalog do that?

Kathleen
Feb 11, 2009 at 5:12 PM
A fairly common scenario in MEF is where I go and add a bunch of assemblies that I have direct references (which contain parts) to the container. It does not cover loading contract references though as Nick mentioned.
 
An example of this might be if I have a WPF app, where I have a bunch of services I want in the container, which I have direct references to. The parts that contain those services might be scattered throughout various assemblies that are in memory. Using the approach above, I could add them all to an aggregating catalog, without having to hardcode which assemblies to add specifically.

Glenn




Feb 11, 2009 at 5:46 PM

Hi Kathleen,

DirectoryCatalog won’t behave this way – I think that the indeterminism in this scenario would be difficult to manage in general use.

E.g. if an importer requests exactly one logger, and there happens to be only one logger in the working set of assemblies, the request would succeed under your implementation. If, on the other hand, execution of code across different assemblies happened to pull another logger into memory, the request would fail with a cardinality constraint violation.

DirectoryCatalog will load all available component definitions up front so that it can give consistent results.

If you do need the functionality you described, you should investigate using a custom catalog – AggregateCatalog can be handy in these cases, as Glenn suggests.

Hope this helps,

Nick

From: KathleenDOllard [mailto:notifications@codeplex.com]
Sent: Wednesday, February 11, 2009 9:36 AM
To: Nicholas Blumhardt
Subject: Re: Catalog for all loaded assemblies [MEF:46797]

From: KathleenDOllard

Nick,

I see this as kind of a two way thing, and in one direction, yes, directory catalog is good.

So, let's say I have a composable app that uses MEF to start a process. While runnning, this process needs to reach out to the outside environment (environment = code that called it), let's say to grab a peice of information, although logging and progress come to mind as well. I am willing to make the assumption that whatever has the information the process needs is loaded. Sure, it might not be, so maybe a directory search if the export isn't found is a good idea. But before I do a directory search, I want to ensure that nothing in memory supports the export. Does the directory catalog do that?

Kathleen

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