Despite the vitriol displayed in my last post concerning the Entity Framework, we are still using it in our proof of concept.  Why?  Because no matter how bad a technology might be, it pays to know as much about it before you absolutely throw it out of the window - ultimately you never know if the deficiencies you initially find can actually be addressed with some more creative coding. 

As it is, while I'm still disappointed with v1 of EF, actually I'm positive about the way it could be going - my own views on this in another post, but for now the least I can do is to point you in the direction of the EF team's blog: http://blogs.msdn.com/efdesign/.  It's clear to me that the team is trying to listen to all views - which can be difficult given the negativity they've been faced with.

Today's post is specifically about what might be a bug in EF, however there is a workaround for it.

[I've redded-out any names that could link this code to anything internal to my company - all you need to know is that the code you're seeing is auto-generated by the EF designer for the ObjectContext-derived class usually called SomethingEntities.  This might seems a bit OTT - but you should see my NDA!]

The method in question is Assembly.GetManifestResourceNames - and is called deep-down in the EF code by the method System.Data.Metadata.Edm.MetadataArtifactLoaderCompositeResource.ResolveAssemblyName, which is in turn called by MetadataArtifactLoader.Create(string, ExtensionCheck, string, ICollection<String>, MetadataArtifactAssemblyResolver).

Believe it or not, I'm paraphrasing here!

I have two scenarios - in one, the exception does not occur, and in the other it does.  However, each time it's practically the same code-base, just a different entry point (one is a test, and the other is a WCF service).  What's common to both is that I have a bunch of dynamically generated assemblies.

The reason is simple - the meta data part of the connection string that is used to construct my ObjectContext-deriving instance - it's the default one that the EF Designer sticks in, usually in the form:

metadata=res://*/CSDLFILE.csdl|res://*/SSDLFILE.ssdl|res://*/MSLFILE.msl;provider=[DB DROVIDER];provider connection string=[CONNECTION STRING].

When the Metadata loader code can't identify a specific assembly name from that metadata part of the connection string, it reflects all the non-System assemblies, probing each one until it finds these resources.  If an assembly is a dynamic one (and, therefore, is in fact an AssemblyBuilder instance, instead of Assembly) the GetManifestResourceNames method fails - because it is indeed not supported by the AssemblyBuilder class.  This search behaviour is triggered by the presence of the wildcard ( * ) character in the meta data string.

The solution?  Short of the EF team adding a catch filter for this exception, or filtering out AssemblyBuilder instances (I've posted a Connect bug here), the only option is to change the wildcard for the full name of the Assembly in which the meta data is to be found; that way the search is not needed.