如何使用源代码管理设置DotNetNuke开发环境？

Question

我的团队正在开发一个新的DotNetNuke Web应用程序，并想了解建议使用源代码管理和自动构建来设置开发环境的建议？我们希望将DNN源代码与我们的自定义模块和扩展源代码分开。

为Visual Studio DotNetNuke的编译的模块模板希望我们的源代码存储在DNN的源代码，并输出到DNN源代码bin目录的DesktopModules目录。这是推荐的结构吗？我宁愿将文件保存在不同的位置，但是在本地运行和调试会变得更加困难，因为每次更改都需要安装模块。另外，自动构建应该如何部署任何更改？

其他人如何设置？有推荐的最佳做法吗？

Answer 1

我们通常坚持保持文件夹中的模块代码DesktopModules和建筑下网站的bin目录。

在源码控制中，我们只映射单个模块，而不是整个网站。根据我们正在处理的内容，模块可能是源代码控制中的整个项目，或者我们可能在同一个项目中有多个相关模块，彼此相邻。

在DNN中自动部署更改有点困难。强烈建议使用构建脚本将您的模块打包为可安装的表单。然后，您可以将可安装软件包复制到网站的Install/Module文件夹中，并获取URL /Install/Install.aspx?mode=InstallResources，该URL将安装该文件夹中的所有软件包。

Answer 2

对于我的源代码控制，我在自己的项目中开发模块。这包含模块代码，测试代码，数据提供程序代码（如果适用）以及其他任何内容。像任何其他项目一样，这将检入到源代码管理中。请注意，模块项目不包含指向特定DNN网站的链接，并且在项目中将DNN引用引用到引用您的目标构建的通用“bin”目录。例如，在我的项目文件夹中，我有\ bin460，\ bin480，\ bin510，\ bin520等。这些文件夹中的每一个都包含一组用于特定DNN版本的二进制文件。这样你就可以针对特定版本进行构建，但是可以针对任何你喜欢的版本进行测试

在一个DNN安装源控制模块中发生的问题是 - 有时不是所有的模块代码的容易单个父目录 下分离 - 不能很好借给PA模块的方法 - 不容易将该项目转移到不同的DNN版本进行开发或测试 - 易于无意中获取DNN解决方案的源控制部件，特别是集成VS源控制解决方案。

此方法编译速度很快，因为您并未尝试编译整个项目。对于测试部署，我有一个构建脚本，将模块的各个部分复制到目标网站。这可以通过编译完成（链接构建脚本），或者在cmd窗口中编译成功后运行。我的构建脚本有一个“目标”环境切换，所以我可以说'dnn520'将构建部署到我的测试dnn520安装。请注意，在此之前您需要手动创建模块配置，但这是一次性工作，您可以使用导出功能来创建.dnn模块清单。

要构建模块封装，投入时间的综合脚本，它会从你的源目录中的各个部分，并压缩它们到一个安装包。将所有部分保留在源代码管理文件夹中，并将它们复制到临时目录中，然后运行命令行zip实用程序（我使用古老版本的pkzip）将其打包到可安装文件中。

这种方法的好处是： - 从安装代码 的模块代码分离 - 只保留模块代码源控制的简单的方法（不必排除所有的网站代码） - 能够迅速在不同的DNN版本 测试出模块 - 包装脚本允许您快速，轻松地构建模块的新版本进行安装测试/部署

缺点是 - 在不能使用魔法绿“走出去”按钮VS（必须手动附加调试器） - 比就地开发更多的安装时间

Answer 3

回应bduke的回答。您应该，也不想在DesktopModules文件夹中构建项目。

1. 这就是开箱即用的所有网站源代码。
2. 这就是你的模块将被“安装”的地方，因此如果有人“更新”或重新安装，那么它将被覆盖
3. 它可以使升级你的应用程序变得更加困难。许多开发人员不明白的想法，不会触及原始源代码文件来修改其行为。因为执行升级时它会被覆盖。

如果你想建立模块，创建一个名为模块一个解决方案文件夹，把你单独的项目模块存在。

1. 如果要调试它们，请将目标调试输出指向web \ bin文件夹。
2. 如果你想安装/部署它们。在发布模式下构建它并通过模块/扩展过滤器进行安装。