我的团队正在开发一个新的 DotNetNuke Web 应用程序，想知道建议使用什么来设置具有源代码控制和自动构建的开发环境？我们希望将 DNN 源代码与我们的自定义模块和扩展源代码分开。
Visual Studio 的 DotNetNuke 编译模块模板希望我们将源代码存储在 DNN 源代码的 DesktopModules 目录中，并输出到 DNN 源代码 bin 目录。这是推荐的结构吗？我宁愿将文件保存在不同的位置，但这样在本地运行和调试就会变得更加困难，因为每次更改都需要安装模块。另外，自动化构建应该如何部署任何更改？
其他人是如何设置的？有推荐的最佳实践吗？
最佳答案
对于我的源代码控制，我在自己的项目中开发模块。其中包含模块代码、测试代码、数据提供程序代码(如果适用)和其他任何内容。像任何其他项目一样，这会被检查到源代码管理中。请注意，模块项目不包含指向特定 DNN 网站的链接，并且项目中的 DNN 引用是对引用目标构建的公共(public)“bin”目录的引用。例如，在我的项目文件夹中，有\bin460 、\bin480、\bin510、\bin520 等。每个文件夹都包含一组特定 DNN 版本的二进制文件。这样您就可以针对特定版本进行构建，但针对您喜欢的任何版本进行测试。
在 dnn 安装中对模块进行源代码控制的问题是 - 有时并非所有模块代码都可以轻松隔离在单个父目录下 - 不太适合 PA 模块方法 - 将项目转移到不同的 DNN 版本进行开发或测试并不容易 - 容易无意中对 DNN 解决方案进行源代码控制，尤其是集成 VS 源代码控制解决方案。
这种方法编译速度很快，因为您不需要尝试编译整个项目。对于测试部署，我有一个构建脚本，它将模块的各个部分复制到目标网站中。这可以通过编译(链接构建脚本)来完成，或者在 cmd 窗口中成功编译后运行。我的构建脚本有一个“目标”环境开关，这样我就可以说“dnn520”将构建部署到我的测试 dnn520 安装中。请注意，您需要先手动创建模块配置，然后才能工作，但这是一次性的工作，您可以使用导出功能来创建 .dnn 模块 list 。
要构建模块包，请投入时间编写一个综合脚本，该脚本将从源目录中获取各个部分，并将它们压缩到安装包中。将所有部分保留在源代码管理文件夹中，并将它们复制到临时目录中，然后运行命令行 zip 实用程序(我使用古老版本的 pkzip)将其打包到可安装文件中。
这种方法的好处是: - 将模块代码与已安装代码分离 - 仅将模块代码保留在源代码管理中的简单方法(不必排除所有网站代码) - 能够快速测试不同 dnn 版本中的模块 - 打包脚本允许您快速轻松地构建新版本的模块以进行安装测试/部署
缺点是 - 无法在 VS 中使用神奇的绿色“go”按钮(必须手动附加调试器) - 比就地开发更多的设置时间
关于version-control - 如何使用源代码管理设置 DotNetNuke 开发环境？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1822893/