我们目前有一个现有的ASP。我们希望迁移到DNN的。NET应用程序。不幸的是，由于时间限制，我们需要一块一块地移动它(或一个功能一个功能……)不管你想怎么看它)。而且，在我们迁移到DNN的过程中，我们希望在现有应用程序中利用当前(DNN 6.0)版本的成员、角色和配置文件提供程序。我似乎有会员提供者工作，但是，我有一个"什么是最好的方法做到这一点"的时刻，关于角色和配置文件提供者。
我的问题是:
- 我是否应该为角色和配置文件提供程序创建一个自定义提供程序，利用DNN核心的代码?还有其他人这么做过吗?
- 或者我可以/应该利用这些DNN组件?我很有兴趣知道如果这是可能的(只是使用组件，更新web。配置等)? ?
任何其他建议将非常感谢!
提前感谢!
就我个人而言，我不认为有理由创建一组自定义的提供商，并且认为您应该使用产品附带的"核心"提供商(因此没有理由进行开发)。您的挑战将是如何将现有用户(及其所有数据)纳入新的DNN安装。如何导入这些数据的选项从自定义开发(用户导入应用程序/模块)到允许用户从各种来源导入的第三方模块各不相同(一般来说，单独使用SQL脚本将很难使用，特别是当您考虑密码散列/安全性以及所有数据如何分布在多个表中时，其中一些在前面的回答中提到)。
如果您打算利用DotNetNuke中的角色、配置文件、用户帐户，那么您可能需要做的不仅仅是实现一个自定义提供者。
DNN与标准ASP交互。NET成员资格提供程序表，但也使用Users表和一个附加表来存储自定义用户配置文件信息的信息。还使用特定于DNN的User Roles表。
因此，当一个帐户被创建或更新时，它会影响很多地方。
我没有这样做，但是DNN使用一个提供者来访问ASP.net成员的东西。它在过去的广告中说，你可以指向另一个系统的ASP成员表，它应该工作。
所以最好让你的应用程序使用标准的asp . net成员表，然后在时机成熟时将DNN指向你的表。