清单是一种配置文件，它告诉DotNetNuke安装程序在运行过程中如何处理项(或属性)
扩展安装过程。
舱单类型
皮肤表现
随着5.0的发布，皮肤从一个必须遵循一些严格约定的简单zip文件变成了一个真正的扩展，与模块和提供程序等其他附加组件一样。虽然皮肤仍然可以以传统的方式打包，但要制作一个利用扩展功能的DNN 5皮肤，皮肤开发人员必须创建一个清单文件。
这有很多优点;
- 我们可以为所有扩展使用一个安装程序
(人们将不得不习惯这一点，但最终它将使安装扩展更容易)
- dnn5皮肤可以有一个版本号。
- 皮肤可以包括许可证文本，发布说明和作者是可见的管理界面的DNN。
- 您可以创建安装多个扩展的包。这意味着您可以将皮肤对象与皮肤以及所需的任何容器打包。如果一个皮肤需要一个特定的皮肤对象，你必须指示用户在dnn4中单独下载并安装它，现在他们可以从一个包中安装。
创建dnn5皮肤
清单用户需要定义一个
皮肤组件。虽然这很容易做到，但一个社区成员创建了一个
在线工具为了简化这个过程。
扩展清单
通常称为DotNetNuke清单文件，该文件告诉DotNetNuke扩展安装程序在安装时如何处理扩展包。这个清单文件与.dnn文件扩展名相关联。在扩展名安装期间，出于安全原因，该文件扩展名被更改为.config文件扩展名(。配置文件扩展名受IIS保护)。
随着时间的推移，扩展安装程序得到了增强，并为新功能添加了支持。到目前为止，已经出版了多个版本。最新的两个版本，也是目前最流行的两个版本:3.0版本(支持DotNetNuke 3.0至4.9核心，也可用于DotNetNuke 5.0及更高的核心版本)和5.0版本(支持DotNetNuke 5.0及更高的核心版本)。
扩展清单包含多个节点，所有节点都在扩展安装期间发挥作用。下面的区域将基于扩展安装程序的5.0版本解释每个部分。
.dnn6扩展名清单文件
从DotNetNuke 6开始(虽然CTP或Beta版本中没有)，就增加了使用DotNetNuke 6特定清单文件的能力。这个.dnn6文件可以与标准的.dnn文件共存，这样就可以在DotNetNuke 5中安装相同的扩展包。6. DotNetNuke . x版本。x版本。扩展提供商想要这样做的主要原因是如果他们想要利用模块的品牌特性或改变模态弹出行为，但他们还没有准备好将所有的开发转移到6。
.dnn6文件清单也将被dnn7和更高版本读取。
包装&包装
该DotNetNuke安装程序允许多个包安装与一个单一的文件上传(即。zip文件)。每个包都是独立于其他包声明的，它们都包含在一个“packages”节点中。值得一提的是，几乎所有的包数据都存储在核心的Packages表中。例子:
还应该知道，每个包等于一个可以在DotNetNuke Extensions模块中管理的扩展，在那里它们按扩展类型分组。现在内核中允许的扩展类型有:
- 身份验证系统
- 容器
- 仪表板控制
- 语言包:(CoreLanguagePack, ExtensionLanguagePack)
- 图书馆
- 模块
- 提供者
- 皮肤
- 皮肤对象
- 小部件
扩展类型列表也可以由开发人员扩展。例如，DotNetNuke Reports模块添加了以下内容:
声明包时，不仅需要指定名称和类型，还必须指定版本。所有这些属性(名称、类型、版本)都在包节点的开头行中声明，并且都是必需的。名称必须是唯一的，并且几乎不会显示在用户界面中(只有在将扩展名编辑为主机时才能看到名称)。DotNetNuke核心扩展通常使用DotNetNuke。x或DNN_x(其中x是扩展名)，所以开发人员应该避免使用这些。一般的经验法则是使用“你的公司”。命名包时使用ExtensionName。type属性、上面列表中提到的可用类型和version属性用于确定如何处理扩展安装。例如，引用版本
包节点中的接下来两个节点用于标识扩展的名称和功能，以便将其显示给超级用户(或主机)。第一个，友好的名称，是如何在扩展页面中引用扩展。友好的名称可以包含空格，并且允许有250个字符。描述是不言自明的，你允许2000个字符。
从DotNetNuke 6.0开始，扩展开发人员可以在这里添加一个名为“iconFile”的节点(在描述之后，在接下来讨论的所有者之前)。这个节点允许自定义品牌图标与扩展相关联。此图标将显示在控制面板的下拉列表中以及扩展页面(其中显示所有已安装的扩展)。请注意，您还必须将此映像文件(最好是.png类型)与可安装扩展名一起包含。
从DNN 7.1开始，清单中添加了一个新元素，表示扩展是否已经过测试并与SQL Azure兼容。这是
元素——根据Azure兼容性，它应该包含true或false。正确的用法是'true'表示正在测试并与SQL Azure兼容，如果不兼容则为false。看到Azure兼容扩展清单检查。
下一组可用的节点是关于扩展作者/所有者的信息，它们嵌套在“所有者”节点中。该所有者部分包含姓名、组织、url和电子邮件，尽管这些信息不是必需的，但应该提供。
在所有者部分之后，还有两个节点应该伴随每个扩展，它们是许可证节点和发行说明节点。开发人员可以链接到一个文件，也可以为每个节点内联包含注释。
在深入研究组件之前，最后一部分是依赖项部分。每个依赖项都必须作为其独立的“依赖项”节点列出，其中必须指定type属性。最常用的类型是“CoreVersion”，其中指定了安装模块所需的DotNetNuke核心的最小版本。
支持依赖“类型”值(不区分大小写):
- coreversion
- 将值与当前DotNetNuke版本进行比较(参见下面的示例)。
- 包
- 将value与核心Packages表中的Name列进行比较(参见下面的示例)。
- 许可
- 类型
- 依赖项列表项(需要更多信息)
下面的例子摘自核心论坛模块:
<包>
.
< friendlyName > < / friendlyName论坛>
DotNetNuke的核心论坛模块
<人>
论坛模块项目
<组织> DotNetNuke公司组织> < /
url //m.halcrogroup.com/Development/Forge/ModuleForums/tabid/820/Default.aspx < url > < / >
< >邮件(电子邮件保护)< / >邮件
< / >老板
<许可证src = " License.txt " > < /许可证>
< releaseNotes src = " ReleaseNotes.txt " > < / releaseNotes >
< >的依赖关系
<依赖type = " CoreVersion " > 05.04.01依赖> < /
< / >的依赖关系
依赖于现有“包”的示例如下，取自于http://multifunction.codeplex.com/
< >的依赖关系
<依赖type = " CoreVersion " > 05.02.00依赖> < /
<依赖type = "包" > WatchersNET.SkinObjects.ModuleActionsMenu依赖> < /
< / >的依赖关系
一个对现有包具有最低版本要求的依赖示例，摘自jQueryMigrateGitHub
jQuery
尽管DNN没有公开一种方法来获取特定. net框架版本的依赖项，但是可以很容易地通过对以前框架版本中不存在的类获取类型依赖项来进行模拟。例如，如果需要将. net 4作为安装的先决条件，则可以依赖于系统。元组类(在。net 4.0中引入):
<依赖类型=“类型”>系统。元组< / >的依赖
在一次安装中安装多个包(因此使用单个清单)时，有几件事需要注意。首先，包按照它们在清单文件中声明的顺序(从上到下)安装。这意味着，如果您正在安装一个包含皮肤对象的皮肤扩展，那么您需要在安装皮肤之前安装皮肤对象(因此，将皮肤对象包放在皮肤包的上方)。在本例中，皮肤对象由正在安装的皮肤使用，因此它需要在皮肤被安装之前可用(否则，皮肤对象将无法正确呈现)。
第二，安装程序用户界面只知道第一个正在安装的包。这意味着在安装程序屏幕中只显示第一个包的组件部分之前的信息(名称、描述、所有者信息、许可和read me备注)。
组件
主题链接