如何使用源代码管理设置 DotNetNuke 开发环境？
我的团队正在开发一个新的 DotNetNuke Web 应用程序，想知道建议使用什么来设置具有源代码控制和自动构建的开发环境？我们希望将 DNN 源代码与我们的自定义模块和扩展源代码分开。
Visual Studio 的 DotNetNuke Compiled Module 模板希望我们将源代码存储在 DNN 源代码的 DesktopModules 目录中，并输出到 DNN 源代码 bin 目录。这是推荐的结构吗？我宁愿将文件保存在不同的位置，但这样在本地运行和调试就会变得更加困难，因为每次更改都需要安装模块。另外，自动化构建应该如何部署任何更改？
其他人是如何设置的？有推荐的最佳实践吗？
My team is developing a new DotNetNuke web application and would like to know what is recommended to setup a development environment with source control and automated builds? We would like to keep the DNN source code separate from our custom modules and extensions source code.
The DotNetNuke Compiled Module template for Visual Studio wants us to store the source code in the DesktopModules directory of the DNN source code and output to the DNN source code bin directory. Is this the recommended structure? I would rather keep the files in different locations, but then it becomes more difficult to run and debug locally as it would require an install of the module for each change. Also, how should an automated build deploy any changes?
How have others set this up? Is there a recommended best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于我的源代码控制，我在自己的项目中开发模块。其中包含模块代码、测试代码、数据提供程序代码（如果适用）和其他任何内容。像任何其他项目一样，这会被检查到源代码管理中。请注意，模块项目不包含指向特定 DNN 网站的链接，并且项目中的 DNN 引用是对引用目标构建的公共“bin”目录的引用。例如，在我的项目文件夹中，有 \bin460 、 \bin480、\bin510、\bin520 等。每个文件夹都包含一组特定 DNN 版本的二进制文件。这样您就可以针对特定版本进行构建，但针对您喜欢的任何版本进行测试。
在 dnn 安装中对模块进行源代码控制的问题是
- 有时并非所有模块代码都可以轻松隔离在单个父目录下
- 不太适合 PA 模块方法
- 将项目转移到不同的 DNN 版本进行开发或测试并不容易
- 容易无意间对 DNN 解决方案进行源代码控制的部分，尤其是集成 VS 源代码控制解决方案。
这种方法编译速度很快，因为您不需要编译整个项目。对于测试部署，我有一个构建脚本，它将模块的各个部分复制到目标网站中。这可以通过编译（链接构建脚本）来完成，或者在 cmd 窗口中成功编译后运行。我的构建脚本有一个“目标”环境开关，这样我就可以说“dnn520”将构建部署到我的测试 dnn520 安装中。请注意，您需要先手动创建模块配置，然后才能工作，但这是一次性的工作，您可以使用导出功能来创建 .dnn 模块清单。
要构建模块包，请投入时间编写一个综合脚本，该脚本将从源目录中获取各个部分，并将它们压缩到安装包中。将所有部分保留在源代码管理文件夹中，并将它们复制到临时目录中，然后运行命令行 zip 实用程序（我使用古老版本的 pkzip）将其打包到可安装文件中。
这种方法的好处是：
- 将模块代码与已安装代码分离
- 仅将模块代码保留在源代码管理中的简单方法（不必排除所有网站代码）
- 能够快速测试不同 dnn 版本中的模块
- 打包脚本允许您快速轻松地构建新版本的模块以进行安装测试/部署
缺点是
- 无法在 VS 中使用神奇的绿色“go”按钮（必须手动附加调试器）
- 比就地开发需要更多的设置时间
For my source control, I develop modules in their own project. This contains the module code, test code, data provider code (if applicable) and anything else. This is checked into source control like any other project. Note that the module project contains no links to a specific DNN website, and DNN references are made in the project to a common "bin" directory that references your target build. For example, in my projects folder, I have \bin460 , \bin480, \bin510, \bin520 etc. Each of these folders holds a set of binaries for a specific DNN version. That way you can build against a particular version but test against any version you like.
The problem with source-controlling a module in place in a dnn install is
- sometimes not all of the module code is easily isolated under a single parent directory
- doesn't lend well to a PA module approach
- not easy to shift the project to a different DNN Version for development or testing
- easy to inadvertently source control parts of the DNN solution, particularly with integrated VS source control solutions.
This approach compiles quickly because you're not trying to compile the entire project. For test deployment I have a build script that copies the various parts of the module into a target website. This can be done via the compile (link the build script) or just run after you've had a successful compile in a cmd window. My build script has a 'target' environment switch, so that I can say 'dnn520' to deploy the build to my test dnn520 install. Note that you need to manually create the module configuration first before this will work, but this is a one-time effort, and you can use the export feature to create your .dnn module manifest.
To build your module package, invest the time in a comprehensive script which will take the various parts from your source directory, and zip them into an install package. Keep all of the parts in your source control folder, and copy them into a temp directory, then run a command-line zip utility (I use an ancient version of pkzip) to pack it into an installable file.
The benefits of this approach is :
- separation of module code from installed code
- simple way of keeping only the module code in source control (don't have to exclude all the website code)
- ability to quickly test out modules in different dnn versions
- packaging script allows you to quickly and easily build a new version of a module for install testing/deployment
The drawbacks are
- can't use the magic green 'go' button in VS (have to manually attach debugger)
- more setup time than developing in-place
我们通常坚持将模块代码保存在
DesktopModules下的文件夹中，并构建到网站的bin目录中。在源代码控制中，我们只映射各个模块，而不是整个网站。根据我们正在处理的内容，模块可能是源代码控制中的整个项目，或者我们可能在同一个项目中有多个相关的模块，彼此相邻。
在 DNN 中自动部署更改有些困难。强烈建议使用一个构建脚本将模块打包成可安装的形式。然后，您可以将可安装的软件包复制到网站的
Install/Module文件夹中，并获取 URL/Install/Install.aspx?mode=InstallResources，这将安装该文件夹中的所有软件包文件夹。We typically stick to keeping the module code in a folder under
DesktopModulesand building to the website'sbindirectory.In source control, we just map the individual modules, rather than the entire website. Depending on what we're working on, a module may be an entire project in source control, or we may have multiple related modules in the same project, living next to each other.
Automatically deploying changes is somewhat difficult in DNN. It's highly recommended to have a build script that packages your module into an installable form. You can then copy installable packages into the website's
Install/Modulefolder, and get the URL/Install/Install.aspx?mode=InstallResources, which will install any packages in that folder.回应 bduke 的回答。您应该但不希望在 DesktopModules 文件夹中构建项目。
如果您想构建模块，请创建一个名为 Modules 的解决方案文件夹，并将单独的项目模块放在那里。
In response to bduke's answer. You should, and don't want to build projects in the DesktopModules folder.
If you want to build modules, create a solution folder called Modules and place your seperate project modules there.