Can I use Entity Framework with ASP.NET Membership?

Question

I'm creating (really, re-creating) an app that has existing user and other data in MS-Access databases. The data will be moved to SQL Server, and part of that involves migrating users. I want to use EF to do ORM, and I am pretty sure I know what the data model will be in SQL Server. I am new to EF but not to ASP.NET, and I'd like to take advantage of the Membership features in ASP.NET. I am thinking about several ways to do this and would like some advice. I've done only a little research about this idea thus far, maybe it's been answered elsewhere. So, here goes a cluster of related questions.

1. Can EF work with directly with ASP.NET Membership through some class or namespace that I'm not aware of?

2. If I transition users to the Membership system, to align their userids with data in other tables should I create another set of tables for user data atop the aspnet_* tables a la DotNetNuke?

3. I want to avoid a situation where I use the built-in Membership functions for only user authentication and switch over to EF context when I'm working with user-tagged data. Seems clumsy to withdraw user info to bind to a column in a GridView by going into a Membership user for every row, but maybe that's what's needed? Do I need to suck it up and replicate the Membership classes in EF for data retrieval purposes?

4. I was thinking of maybe implementing some kind of EF provider for Membership, on the idea that maybe then the provider could sit inside the overall EF data model. Is this crazy talk? (I've never written my own provider before)

Feel free to tell me I am not making any sense.

Answer 1

Why not do it the other way around? You can implement your own Membership provider for asp.net, that uses the model you want/need.

If the features you need aren't a complete match with the built-in asp.net membership implementation, you can just roll your own provider. If you will use just a couple features, you will have to implement just a couple methods (you don't have to fill implementation for all the methods). If you need more features than it supports, using the membership provider might get in your way.

Answer 2

1. We do, but we don't map the Membership tables. You shouldn't presume use of the SQL membership provider.
2. We map the user identity, not the DB id. Subtle, but important. Again, remember that there are other membership providers (e.g., domain auth).
3. Can you clarify the question? You won't need to replicate all of membership info in your EF model, but you will need a list of known identities.
4. No, not at all crazy, but difficult and probably unnecessary.