Reusing DotNetNuke membership/role/profile providers

We currently have an existing ASP.NET application that we want to migrate to DNN. Unfortunately, due to time constraints, we need to move it piece-by-piece (or function-by-function... however you want to look at it). And, we would like to leverage the current (DNN 6.0) version of the membership, roles and profile providers in our exis开发者_JAVA百科ting application while we are moving to DNN. I seem to have the membership provider working, but, I am having one of those 'what is the best way to do this' moments in regards to the roles and profile providers.

So, my questions are:

1. Should I create a custom provider for roles and profile providers leveraging code from the DNN core? Has anyone else done this?
2. Or can/should I leverage the DNN assemblies for these? I'm very interested to know if this is even possible (just using the assemblies, updating web.config, etc.)??

Any other suggestions would be greatly appreciated!

Thanks in advance!

---

Personally, I don't see a reason to create a custom set of providers and feel you should be fine using the 'core' ones that ship with the product (thus no reason for development). Your challenge is going to be how you will get your existing users (and all their data) into the new DNN install. Your options for how to import this data vary from custom development (of a user import app/module) to third party modules that allow user import from various sources (in general, SQL scripts alone will be difficult to use especially when you consider password hashing/security and how all the data is spread out in multiple tables some of which were mentioned in the previous answer).

---

If you are going to leverage the roles, profiles, user accounts in DotNetNuke then you would probably need to do more then just implement a custom provider.

DNN interacts with the standard ASP.NET membership provider tables but also uses a Users table as well as an additional table to store information for custom user profile information. Also uses a User Roles table specific to DNN.

So when an account is created or updated it affects a lot of places.

I've not done it, but DNN uses a provider to access the ASP.net membership stuff. It's been advertised in the past that you can point that at another systems ASP membership tables and it should work.

So it might be best to have your app use the standard asp net membership tables, then just point DNN to your tables when the time comes.