1

This question follows on from previous questions like Does Entity Framework 6 support .NET 4.0?
My question is specifically, how do I make use of the NotMapped data annotation with EF6 and .NET v4.0?

Most articles I can find assume the developer has also migrated to .NET v4.5 or later, where the data annotations namespace has been moved to System.ComponentModel.DataAnnotations.Schema and lives in the System.ComponentModel.DataAnnotations dll.

Community
  • 1
  • 1
MarkHone
  • 381
  • 5
  • 12

2 Answers2

3

The .NET 4.0 version of Entity Framework 6 contains a definition of NotMappedAttribute directly in EntityFramework.dll. It exists in the same namespace, namely System.ComponentModel.DataAnnotations.Schema.

You will need to make sure you have the .NET 4.0 version of EF, though. If your project was previously targeting .NET 4.5, and you added EF at that time, you've got the .NET 4.5 version of EF. Changing the project to .NET 4.0 is not enough to fix this. You'll need to remove EF from your project and re-add it.

  • @MarkHone Heh, yes, I didn't think of that possibility, but I suppose if you've not got a reference to EF at all in the project that wants to use `NotMappedAttribute`, that's a special case of not having got a reference to the .NET 4.0 version of EF :) Glad that you've got it working now. –  Jan 16 '14 at 14:38
0

I solved my own problem (by opening me eyes!). The data entities are in a separate project, which didn't include a reference to Entity Framework. Installing the same EF6 NuGet package in the entities project resolves the issue.

UPDATE: I had further issues with EF6 so I rolled back to EF5 and, instead, created a new ViewModel that included the property I wanted to add to the orginal entity. This maintains the separation of concerns that were compromised in the above solution in a satisfactory manner. It also mirrors the approach taken elsewhere in the code-base.

MarkHone
  • 381
  • 5
  • 12
  • 1
    Why are your entities (assuming POCO) in a separate project? Is it for the purpose of removing dependency on a specific data implementation? If so, by putting a reference to EF into your poco project, you are coupling your domain with your persistence. Just be aware that if you ever want to refactor to a different data provider than EF, you will now have to deal with it in multiple projects. – Aaron Palmer Jan 16 '14 at 14:55
  • 1
    @AaronPalmer: yes you are abolsutely correct - I've just defeated the whole purpose of separating the entity classes! I think I've got another solution that will maintain the intended decoupling and will update my self-answer once I'm happy. – MarkHone Jan 16 '14 at 15:06
  • 1
    Think of EF entities as data entities, not domain objects. This raises some interesting problems when attempting to decouple POCO entities. Two possible routes would be, (1) leave them with the data layer and gain all of the EF goodness (like those data annotations) and have some mechanism to map to domain objects for business logic and behavior. Or (2) decouple the POCOs and treat them like domain objects themselves, at which point you must refrain from using specific EF features on them. Also, beware if you are autogening them that you don't overwrite custom code (use partials or inherit) – Aaron Palmer Jan 16 '14 at 16:49
  • @AaronPalmer: thanks for your thoughts. The system is designed around route 2 as you've defined it above so I created a new ViewModel that included the property I wanted to add. This fits better with the rest of the application. – MarkHone Jan 17 '14 at 12:25