I am trying to persist a workflow that has a EF POCO in it as a variable. When I try to persist (and workflow is trying to serialize the object), I get an error:
Type 'System.Collections.Generic.ICollection`1[MyObject]' cannot be
serialized. Consider marking it with the DataContractAttribute
attribute, and marking all of its members you want serialized with the
DataMemberAttribute attribute. If the type is a collection, consider
marking it with the CollectionDataContractAttribute. See the
Microsoft .NET Framework documentation for other supported types.
Any ideas how to get around this?
Turning it into a list is probably the easiest way to get around this. The problem is it doesnt know how to serialise your collection
I found the answer here:
Get serialization error when try and submit EF4 entity via WCF
It turns out the FixupCollection (in Entities.tt) does not have the DataContract attribute. Once I added that, the issue was resolved.
Related
I am doing a proof of concept in a line of business application where I want to swap out the current C# Code-First Entity Framework implementation with a F# one. I am following this article which seems to work pretty well, but I was hoping to use FSharp record types instead of the classes that the article uses. When I try and add a data annotation to a record type like this:
type Family = {[<Key>]Id:int; LastName:string; IsRegistered:bool}
I get the following error:
Error 1 The type 'Key' is not defined
Is there a way to use data annotations with record types? Apparently, EF Code-First needs annotations...
Record types support attributes just fine (and with the syntax you have).
Check if your reference to System.ComponentModel.DataAnnotations is in order, that's where KeyAttribute is defined.
Edit: EF wants to work with properties, that's why using a record doesn't mesh well with EF. You can still make it work in F# 3.0+ by marking the record with CLIMutable attribute (this generates property setters and a parameterless constructor which are taken for granted by C#-centric frameworks and libraries).
The article you're looking at was written with F# 2.0 in mind - CLIMutable wasn't around yet and there was no way of using records for that.
So I have run into a situation where I need to use the Entity Framework (DbContext) with databases whose columns are not known at compile time. Basically I don't have the luxury of hard coding a customTable class to put into the DbSet.
The only thing I can think of for solving this issue is using Reflection.Emit to create a customTable class at run-time based on information I glean by interrogating a database.
I was not able to find any information of solving this issue, but I am very new to working with the Entity Framework so maybe a solution would be more obvious to someone more experienced.
I feel like there should be a cleaner way than using Reflection.Emit to dynamically create a class to feed DbSet.
If I am way off base for the intended use of the Entity Framework that information would be useful as well.
Hi I'm investigating this problem too and I have found what seems like the solution.
http://romiller.com/2012/03/26/dynamically-building-a-model-with-code-first/
tells you how to make a DbContext into which you add a new DbSet using a type as a parameter. You can create this type using the Dynamic Linq Library:
http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
It has a method called CreateClass which will allow you to dynamically build a POCO class definition from a list of field names and load it, you can then create a DbSet using the new type you have created.
You can then get a non-generic DbSet from your updated DbContext using
db.Set(type)
where 'type' is a variable holding your new type. This can be worked on using the linq predicates in the dynamic linq library.
Incidentally, my application is for a CMS where new modules can add fields to the core data table for the CMS, and I don't want to use DI as its too inflexible as no given module will be able to provide a type which has all the fields it needs and all the other unknown modules might also need.
James
we use Azure Caching directly (and not through one of the available Entity Framework wrappers). Apparently, for distributed caching, we need to serialize the objects. Unfortunately, this causes issues with lazy-loaded DbContext-based proxies used for navigation properties.
I see we can use a custom serializer in order to map proxies to empty collections (if not loaded) or to normal objects (if loaded), but I am not sure about the implementation. One possible implementation can be based on the one used by WCF, but I am not sure Azure works the same way.
The ideal solution (and that's why I point to ProxyDataContractResolver) would be one where, when serialization happens:
IF the navigation property has been already loaded the data would be serialized as if it were a normal Collection,
and if they are not loaded, they won't be serialized (I would like lazy loading to work back after deserialization for the latter case, but it's acceptable if it doesn't).
Has anyone manually fixed that problem in an elegant way?
Thanks in advance!
I will presume that if you are wanting to cache EF objects, you don't require lazy loading or change tracking on those entities.
I believe that both of those are enabled through object proxies that will cause serialization issues (since you don't want to serialize the proxy).
If you disable the property DbContext.Configuration.ProxyCreationEnabled then serialization of the actual object, not the proxy, should work fine. This is typically required when returning POCO objects over WCF but is likley the same for other serializations scenarios such as this.
If you detach the EF entity from the DbContext before serializing it, that disables lazy loading, so your custom serializer won't try to serialize anything that isn't already part of the entity's graph.
Then when you get it back from the cache, if you attach it to a new (identical) DbContext, that should reenable lazy loading.
(Caveat: once you detach the entity from the context, any new queries that include that same object will create a new, attached, copy, so you will need to code with some care to avoid running into trouble with multiple potentially-different versions of the same object running around. But that said, this should let you do what you want.)
I am experiencing the following error when I try to assign a new reference to a navigation property. So far, all of my searching has not really turned up anything useful, so I was wondering if I might get any help from SO on this.
Metadata information for the
relationship
'CustomerModel.FK_Execution_ClientBlock'
could not be retrieved. Make sure that
the EdmRelationshipAttribute for the
relationship has been defined in the
assembly
What is strange is that all of my code works. This is only occurring during a unit test. I assume it's because I'm using a mocking framework (MOQ) to mock up this particular EF object.
We're using the version of EF that comes with .net 3.5 if that helps.
I have previously had a similar problem, in my case the solution was this: MetadataException when using Entity Framework Entity Connection
Basically you need to add the name of the dll to the metadata connection string
In ADO.net EF, when should you call the context.Attach() and the context.Detach() methods and how do these calls affect the data being returned or being inserted?
This is one of those questions where, "If you have to ask, you probably should not be doing it." The Entity Framework will implicitly attach entities in cases where it is obvious that this needs to happen. You really only ever need to explicitly attach and detach entities in cases where you are using more than one ObjectContext at once. Because this can be quite confusing, due to the implicit attachment which happens in the course of normal Entity Framework operations, I strongly recommend that people new to the Entity Framework use only one ObjectContext at a time. If you do this, you should never need to explicitly call Attach or Detach.
Calling, say, Attach does not really affect the data returned, insofar as it's scaler properties are concerned. But if it refers to other entities which are already loaded into the context into which it is attached, then these properties will be pre-populated without explicit loading. That said, entities returned from a query are already attached, so you cannot attach them.
Attaching Objects (Entity Framework)
http://msdn.microsoft.com/en-us/library/bb896271.aspx
Detaching Objects (Entity Framework)
http://msdn.microsoft.com/en-us/library/bb738611.aspx