"The current setup is limiting because of our original implementation. Until this is complete I think any custom provider will have some problems working properly. "
this isn't limiting, its just plain impossible to use a DNN portal as a slave for an other application. And the promise of being able to swap out providers with an other just doesn't work. the way it is done in DNN defeats the entire purpose of the membership abstraction.
On the other hand I made some progress in forcing every portal to use application 0 for membership.
Doh, it complains the role "Administrators" already exists when adding a new portal, and aborts operation. This leaves me with a half installed portal wich I can't even delete because DNN thinks the role administrators doen't exist even tough it exists in the membership application <= I consider this a bug
DNN memebrship should accept the fact that a role can already exist befor installing. It should also accept the fact that membership data can change without it being notified.
I know DNN4 has some compatibelity issues with DNN2, but when you trap a membership related error. DNN should check if it can't correct itself by re-syncronizing with ASP.NET membership before it decides to blow up the portal
What are you guys planning for the next release that will make my life easier?
Being able to specify the application name a portal should use would be nice.
Managing userpools and portals as seperate objects and being able to link a new portal to any existing userpool would be even nicer. (this could easily simulate the current behavior of 1 userpool / portal)