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

时间:2009-11-30 22:34:05

标签: version-control build-automation development-environment dotnetnuke

我的团队正在开发一个新的DotNetNuke Web应用程序,并想知道建议使用源代码控制和自动构建设置开发环境的建议是什么?我们希望将DNN源代码与我们的自定义模块和扩展源代码分开。

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

其他人如何设置?是否有推荐的最佳做法?

3 个答案:

答案 0 :(得分:7)

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

源代码控制dnn安装中的模块的问题是 - 有时并非所有模块代码都可以在单个父目录下轻松隔​​离 - 不适合PA模块方法 - 不容易将项目转移到不同的DNN版本进行开发或测试 - 很容易无意中将DNN解决方案的源控制部分,特别是集成的VS源控制解决方案。

这种方法可以快速编译,因为您没有尝试编译整个项目。对于测试部署,我有一个构建脚本,可以将模块的各个部分复制到目标网站中。这可以通过编译(链接构建脚本)完成,或者在cmd窗口中成功编译后运行。我的构建脚本有一个'目标'环境开关,所以我可以说'dnn520'将构建部署到我的测试dnn520安装。请注意,您需要首先手动创建模块配置,但这是一次性工作,您可以使用导出功能创建.dnn模块清单。

要构建模块包,请将时间投入到一个综合脚本中,该脚本将从源目录中获取各个部分,并将它们压缩到安装包中。保留源控件文件夹中的所有部分,并将它们复制到临时目录中,然后运行命令行zip实用程序(我使用古老版本的pkzip)将其打包到可安装文件中。

这种方法的好处是: - 从安装的代码中分离模块代码 - 只保留源代码管理中的模块代码的简单方法(不必排除所有网站代码) - 能够快速测试不同dnn版本的模块 - 打包脚本允许您快速轻松地构建新版本的模块以进行安装测试/部署

缺点是 - 不能在VS中使用魔术绿色'go'按钮(必须手动连接调试器) - 比现场开发更多的设置时间

答案 1 :(得分:6)

我们通常坚持将模块代码保存在DesktopModules下的文件夹中,然后构建到网站的bin目录。

在源代码管理中,我们只是映射各个模块,而不是整个网站。根据我们正在进行的工作,模块可能是源控制中的整个项目,或者我们可能在同一个项目中有多个相关模块,彼此相邻。

在DNN中,自动部署更改有点困难。强烈建议使用构建脚本将模块打包成可安装的形式。然后,您可以将可安装程序包复制到网站的Install/Module文件夹中,并获取URL /Install/Install.aspx?mode=InstallResources,它将在该文件夹中安装任何程序包。

答案 2 :(得分:0)

回应bduke的回答。您应该,并且不希望在DesktopModules文件夹中构建项目。

  1. 这就是网站开箱即用的所有源代码。
  2. 这就是模块将被“安装”的地方,因此如果有人“更新”或重新安装模块,那么它将被覆盖
  3. 它可以使您的应用程序升级变得更加困难。许多开发人员不明白没有触及原始源代码文件的想法来修改他们的行为。因为在执行升级时它会被覆盖。
  4. 如果要构建模块,请创建一个名为 Modules 的解决方案文件夹,并将单独的项目模块放在那里。

    1. 如果要调试它们,请将目标调试输出指向web \ bin文件夹。
    2. 如果要安装/部署它们。在发布模式下构建它并通过Module / Extension过滤器安装它们。