Reputation: 10957
I'm getting the following exception when using ExecuteStoreQuery
to retrieve current database date:
The types in the assembly 'XYZ' cannot be loaded because the assembly contains
the EdmSchemaAttribute, and the closure of types is being loaded by name.
Loading by both name and attribute is not allowed.
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(
ObjectItemCollection objectItemCollection, Assembly assembly,
Boolean loadReferencedAssemblies, EdmItemCollection edmItemCollection,
Action`1 logLoadMessage)
at System.Data.Metadata.Edm.MetadataWorkspace.ImplicitLoadAssemblyForType(
Type type, Assembly callingAssembly)
at System.Data.Objects.ObjectContext.ExecuteStoreQueryInternal[TElement](
String commandText, String entitySetName, MergeOption mergeOption,
Object[] parameters)
at (my method)
Where the method in question contains
var timestamp = context.ExecuteStoreQuery<DateTime>("SELECT GetDate() ").First();
I have used canonical function CurrentDateTime
before, but that caused this exception also in debug configuration. Now it is thrown only in release config.
I have found this exact exception mentioned only a couple of times, mostly it was connected to mixing code first and database first approaches in one assembly, which I believe I've ruled out in my case.
The generated code does indeed contain
[assembly: EdmSchemaAttribute()]
but I don't know which type(s) have caused that - I know of none and don't know how to find them.
If I only use LINQ to Entities, it all seems to work.
For the time being, I rely on our server times being synchronized and don't query DB time at all - it's not recommended, but sadly it wouldn't be the first thing to rely on that in our codebase.
And the questions:
What could be the cause for the code generator to include the said attribute? How can I prevent that? What could be a reasonable workaround (importing a stored procedure containing SELECT GetDate()
seems like an overkill)? Also why does this only happen in release configuration? I have found no information on EF optimizations/differences based on compiler symbols and options...
Upvotes: 2
Views: 1335
Reputation: 31610
Historically (in EF1) EF only could use entities derived from EntityObject class and attributed with a myriad of attributes - e.g. each entity had to have the EdmEntityType attribute, each property had to have the EdmProperty attribute and so on. The assembly with entities had to have EdmSchemaAttribute. When loading types EF looks for the EdmSchemaAttribute and if it finds it it knows that this assembly contains EntityObject based entities that need to be loaded. In EF4 the support for POCO types was added. Now you no longer have to have any attributes and types are matched with your model by convention. However the restriction is that you cannot mix POCO and non-POCO types (hence the exception you get). The default code generator in VS2008 SP1 and VS2010 generates EntityObject based entities and ObjectContext based context. There are non-POCO entities and to make it possible for EF to find them the EdmSchemaAttribute is added. In VS2012 the default is to generate POCO entities and the EdmSchemaAttribute is not generated (it would actually prevent finding the POCO entities). Finally, there are T4 templates for VS2010 on VS code gallery you can use to generate POCO entities from the designer. You just need to add the templates to your project and change "Code Generation Strategy" from "Default" to "None" in the designer.
Upvotes: 2