将Url主定制Url提供程序转换为DNN扩展Url提供程序

Url Master模块的一个关键特性是能够根据您自己的目的进行扩展——无论是为特定模块创建友好的Url方案，还是完成一组特定重定向的任务。当DNN 7.1最初发布时，高级Url诞生了，并随之而来的是旧Url Master自定义Url提供程序功能的改编。这些现在被称为“扩展URL提供程序”。这个想法是完全相同的-为DNN平台提供一个扩展点，开发人员想要控制整个URL以达到他们的目的。其实施在很大程度上是相同的，但在一些小地方有所不同。

由于这种差异，一些为他们的URL主安装构建了自定义URL提供程序的人需要为内置的DNN功能创建等效的提供程序——实际上，如果你想从URL主切换到DNN高级URL，但你依赖自定义URL提供程序来实现这一目的，这是一个障碍。我鼓励每个人都这样做——从Url管理转向使用高级Url有很多好处。

这篇博客文章给出了一个关于如何将Url Master - spec自定义Url提供程序转换为DNN扩展Url提供程序的顶层运行，而不引入任何错误或必须重写它。

转换代码

我建议的第一件事是将整个源代码项目从当前位置复制到一个新位置。您希望确保拥有现有代码的备份。你可以在源代码控制中进行分支，启动一个全新的项目——无论你想做什么，只要开始在一个新的项目副本上工作。

在这个例子中，我将逐步完成'的转换iFinity Url重定向提供者和DNN的意思是一样的DNN Url重定向提供者”。

为了及时进行，打开要转换的代码并准备在代码编辑器中编辑(记住，对已保存的副本执行此操作!)。我建议在你修改任何东西之前，先进行一个工作构建——这将有助于确保你一次只处理一个问题，试图正确地编译它。

转换过程的步骤

主要的区别是URL Provider主类将从一个完全不同的父类继承。这意味着要更改项目中的所有引用。

1.从代码中删除Url Master引用，并确保DotNetNUke.dll引用是7.1或更高版本。

-在项目引用中，删除对Url主程序集的引用[红色箭头]

-再次检查以确保您的DotNetNuke程序集引用指向7.1(或更高版本)-这将需要通过检查文件位置的版本或使用Visual Studio中的对象浏览器来完成。

-确保将项目的构建属性设置为。net 4.0或更高版本。

一旦完成了这一步，您将得到一个破碎的构建，因为您的代码中会有指向错误位置的引用。

2.删除所有的URL Master引用和using语句，并替换为DotNetNuke.Entities.Urls

任何对' ModuleFriendlyUrlProvider '的引用现在都是' ExtensionUrlProvider '

-任何对WebControl的引用，IProviderSettings都会变成PortalModuleBase, IExtensionUrlProviderSettingsControl

更改这些值将旧类型的引用指向DotNetNuke.Entities.Urls命名空间中的新类型。

当这完成后，应该没有更多的引用iFInity.DNN.Modules。UrlMaster*。

3.重新重载旧的ModuleFriendlyUrlProvider

- FriendlyName不再被支持-这个应该被移除。

-不再支持islicented -这应该被移除如果您的代码有许可解决方案，则需要以另一种方式将其合并。“isllicensed”与URL Master许可计划合作，突出显示未获许可的提供商。

- settingscontrolsrc不再支持- ' Settings ' UserControl的位置现在在扩展清单文件中指定。

您将需要为提供者构建一个新的构造函数方法——新的设计在实例化时不包含提供者的属性。事实上，重载构造函数通常没有任何意义，但是您必须将初始化代码放入一个例程中，并确保它被重载中的*所有*调用，以确保在代码中可能需要的所有自定义属性都被正确加载。

在本例中，在读取构造函数期间，有三个属性被读入。现在必须将这些变量移到在提供程序本身的正常操作中调用的初始化例程中——作为开发人员，您不能相信成员级变量在绑定到构造函数方法时已经为您实例化了。

4.重新重载旧的IProviderSettings

IProviderSettings接口允许自定义设置控件检索/存储特定于提供程序的键/值对。该接口不再存在，也没有直接的对等物。

—LoadSettings(provider)和UpdateSettings(provider)变成LoadSettings()和SaveSettings()。将需要负责从. provider属性读取/写入提供者。

新的加载/保存设置使用ExtensionUrlProviderInfo类，该类使用一个轻量级对象来保存实际设置(portalId、门户设置等)。任何使用旧IProviderSettings格式的代码都可能使用实际的提供者对象来来回传递值以进行保存/读取，因此需要更新。

5.更新清单文件

在Url Master特定的提供者中，开发人员有必要制作一套web。config XML合并语句，为要加载的提供程序创建正确的定义。这不再是DNN实现的情况。提供者的加载由提供者的配置处理，而提供者的配置又是由清单组件类型的一级成员控制的。因此，提供商将不需要操纵网络。配置文件，但必须包括一个特定的'组件'类型的安装过程。

-每个扩展URL提供程序必须在依赖项部分中有最小DNN 7.1版本，以防止在早期DNN构建上安装。

每个扩展URL提供程序都需要一个“UrlProvider”类型的组件声明。这个组件定义的值是:

1. name:显示给管理员的友好名称
2. type:提供者中类的完全限定类型，它继承自ExtensionUrlProvider类型。
3. settingsControlSrc:用于加载设置页面的用户控件的相对路径位置。这是直接从Admin->站点设置页面的提供者定义中弹出的加载。
4. redirectAllUrls:如果为真，提供者' redirect '方法重载将被调用为门户的每个请求。
5. replaceAllUrls:如果为真，提供者' change friendly url '方法重载将在门户的DNN中的每个NavigateURL()调用中被调用。
6. rewriteAllUrls:如果为真，提供者'重写'方法将对门户的每个请求被调用
7. desktopModules:提供程序应该与安装的DesktopModule相关联，因为重定向、重写和替换调用应该只发生在与模块相关联的页面上。在这个例子中，URL重定向提供程序是一个没有关联DNN模块的通用提供程序，因此它有一个空的' desktopModule '链接。

注意，对于重定向/替换/重写url，通常是与DesktopModule记录的关联决定哪些请求/ navigateURL()方法调用也通过特定的提供程序运行。在这个例子中，情况并非如此。

6.编译、安装和测试

您的扩展URL提供程序现在应该编译OK。此时，您应该将其打包到一个安装包中，并将其安装到一个测试站点上，并使其通过测试。如果您正在替换Url Master自定义提供程序，您应该能够直接进行测试，以确保所有现有Url都像以前一样工作。请注意，您必须先将URL主安装转换为使用DNN高级URL -除非使用“高级”模式的URL，否则DNN不会加载提供程序。

如果您已经转换了自定义URL提供程序，请确保通过评论让人们知道。您甚至可以将有用的提供程序上传到DNN Url提供商Codeplex网站，这样其他人就可以从你的辛勤工作中受益。如果是这样的话，请与我联系，我可以办到。