2
votes

I've been trying to load the standard ASP.NET SimpleMembership (SM) classes into my EntityFramework (EF) model, but keep running into a few brick walls. I want to use the UserProfile table as a class in my model to bind applications to certain users, then let an admin decide which user can see/edit specific applications.

The way I'm doing it now is running the EF-generated .sql over the .mdf file ASP attaches to the DB at runtime. Then run 'Update Model from Database' in EF. The result is the following pic:

Blue=My EF classes/Green=imported ASP SM classes

The User class should be replaced with UserProfile (and UserType by Roles), but this won't run because of ambiguity between the EF UserProfile and the SM UserProfile. ASP's internal code can't seem to handle that:

The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'UserProfile'

I've tried renaming the UserProfile entity to something like aspnet_UserProfile, but it results in EF not being able to find the corresponding table (because that's still named UserProfile and it should because that's where SM reads).

Is this even possible? Or am I approaching this from the wrong angle?

Small side-question: why is the .mdf a standard MVC project uses so small compared to the classes the aspnet_regsql.exe tool adds?

2

2 Answers

0
votes

EF doesn't allow you to have class that differs only by namespace. You can rename the entity as you did but change the mapping so the table name is still UserProfile. See mapping details window. Another option is to let the mapping unchanged (after changing entity name so you have a table name different from 'UserProfile') and specify it in the initialisation of your identity provider WebSecurity.InitializeDatabaseConnection.

The table you see are simplified and allows better integration than the old way to do SQL Membership (aspnet_regsql). If you want more information about new identity and background on membership, see the Introduction to ASP.NET Identity

0
votes

Note that the Simple Memebership provider comes with :

  • It was hard to persist membership system data in a non-relational store.
  • You can't use it with OWIN.
  • It doesn't work well with existing ASP.NET Membership providers, and it's not extensible.

Entity Framework uses only class names to identify the type mapped in EDMX and namespaces are ignored - it is a convention to allow mapping classes from different namespaces to single model. From your description, it seems that you would have two same named entities and because of the reason I mentioned above, it throws the error.

But you can name your classes in BLL differently (You have used classes with the same name - EF uses only class names to identify the type mapped in EDMX (namespaces are ignored)) and rename the entities as the workaround.