我的团队正在开发一个新的 DotNetNuke Web 应用程序，并且想知道在设置具有源代码控制和自动构建的开发环境时有什么建议？我们希望将 DNN 源代码与我们的自定义模块和扩展源代码分开。
Visual Studio 的 DotNetNuke 编译模块模板希望我们将源代码存储在 DNN 源代码的 DesktopModules 目录中，并输出到 DNN 源代码 bin 目录。这是推荐的结构吗？我宁愿将文件保存在不同的位置，但是在本地运行和调试变得更加困难，因为每次更改都需要安装模块。此外，自动化构建应如何部署任何更改？
其他人是如何设置的？有推荐的最佳做法吗？
【问题讨论】：
标签： version-control build-automation development-environment dotnetnuke
对于我的源代码控制，我在自己的项目中开发模块。这包含模块代码、测试代码、数据提供者代码（如果适用）和其他任何内容。就像任何其他项目一样，这被检查到源代码控制中。请注意，模块项目不包含指向特定 DNN 网站的链接，并且 DNN 引用在项目中指向引用您的目标构建的公共“bin”目录。例如，在我的项目文件夹中，我有 \bin460、\bin480、\bin510、\bin520 等。这些文件夹中的每一个都包含一组特定 DNN 版本的二进制文件。这样您就可以针对特定版本进行构建，但可以针对您喜欢的任何版本进行测试。
在 dnn 安装中对模块进行源代码控制的问题是 - 有时并非所有模块代码都可以轻松隔离在单个父目录下 - 不适合 PA 模块方法 - 不容易将项目转移到不同的 DNN 版本进行开发或测试 - 容易无意中对 DNN 解决方案的源代码控制部分进行源代码控制，尤其是集成 VS 源代码控制解决方案。
这种方法编译速度很快，因为您不需要编译整个项目。对于测试部署，我有一个构建脚本，它将模块的各个部分复制到目标网站中。这可以通过编译（链接构建脚本）来完成，或者在您在 cmd 窗口中成功编译后运行。我的构建脚本有一个“目标”环境开关，所以我可以说“dnn520”将构建部署到我的测试 dnn520 安装。请注意，您需要先手动创建模块配置，然后才能使用，但这是一次性的，您可以使用导出功能来创建 .dnn 模块清单。
要构建您的模块包，请花时间编写一个综合脚本，该脚本将从您的源目录中获取各个部分，并将它们压缩到安装包中。将所有部分保存在源代码控制文件夹中，并将它们复制到临时目录中，然后运行命令行 zip 实用程序（我使用的是 pkzip 的旧版本）将其打包到可安装的文件中。
这种方法的好处是： - 模块代码与已安装代码的分离 - 在源代码管理中仅保留模块代码的简单方法（不必排除所有网站代码） - 能够快速测试不同 dnn 版本的模块 - 打包脚本允许您快速轻松地构建新版本的模块以进行安装测试/部署
缺点是 - 不能在 VS 中使用神奇的绿色“开始”按钮（必须手动附加调试器） - 比就地开发更多的设置时间
【讨论】：
我们通常坚持将模块代码保存在DesktopModules 下的文件夹中，并构建到网站的bin 目录中。
在源代码控制中，我们只是映射各个模块，而不是整个网站。根据我们的工作，一个模块可能是源代码控制中的整个项目，或者我们可能在同一个项目中有多个相关模块，彼此相邻。
在 DNN 中自动部署更改有些困难。强烈建议使用构建脚本将您的模块打包成可安装的形式。然后，您可以将可安装包复制到网站的 Install/Module 文件夹中，并获取 URL /Install/Install.aspx?mode=InstallResources，它将安装该文件夹中的所有包。
【讨论】：
响应 bduke 的回答。您应该并且不想在 DesktopModules 文件夹中构建项目。
如果您想构建模块，请创建一个名为 Modules 的解决方案文件夹，并将您的单独项目模块放在那里。
【讨论】：