ASP.NET网站部署最佳实践资源建议

Question

我查看了相关的问题，而且他们中没有人提供了我正在查找的信息。

目前，我工作的团队针对错误修复/增强部署了单个.aspx（和.aspx.vb）文件。我试图影响变化，因为我确实认为部署“整个编译站点”不太容易出错。由于这是一件事情已经发生的重大变化，我的建议已经遇到了很大的阻力。

由于我的google-fu最近没有达到标准，我希望SO社区可以告诉我，我脱离了我的摇杆，并且移动单个文件没有任何问题，或者指向我真的很好的资源，可以让我做出更强大的情况。

编辑：

这已经全部伟大的信息，并加强我已经做的论据，任何人都可以争论的另一面？

Answer 1

对我个人而言立即回滚是最重要的。在追踪变化时，网站项目再次非常困难。

你可以找到一个很好的详细比较here。我在这里复制这篇文章。

1）部署。如果你需要就地部署，这个模型是完美的。但是，由于您以明文形式显示您的逻辑，因此不推荐。所以，任何有权访问物理服务器的人都可能会弄乱你的代码，你永远不会注意到这一点。你可以尝试做预编译的网站，但是你会得到很多dll和几乎不可触及的aspx文件。微软认识到这一限制并发布了Web部署项目工具。

2）您需要跟踪您在本地更改的内容以及上传到生产服务器的内容。没有版本控制。Visual Studio具有Web Copy工具，但该工具无法提供帮助。我不得不建立自己的工具，它可以跟踪基于Visual Source Safe的变更。

3）当您按F5进行调试执行时，只需2分钟即可编译并执行整个项目。当然你可以附加调试器到现有的线程，但这不是一个明显的解决方案。 4）如果你试图在飞行中产生控制，你将会遇到第一个无法解决的限制。如何引用其他页面和控件。页面和控件编译发生在每个目录的基础上。在最好的情况下，你将获得每个目录的汇编，最糟糕的情况是每个页面或控件都将获得它自己的程序集。如果您需要从控件或其他页面引用另一个页面，则需要使用@Reference指令显式地将其导入。

所以对于，

customControl = this.LoadControl（ “〜/控制/ CustomUserControl.ascx”）作为CustomUserControl;

你需要，

但是，如果你想真正动态添加的东西，不能把所有适当@Reference指令是什么？或者如果你正在创建服务器控制并且它没有ascx文件，那么你没有@Reference的地方？由于每个控件都有自己的组件，因此几乎不可能做反射。

重新出现在Visual Studio 2005 SP1中的Web应用程序项目。他们解决了上述所有问题。

1）部署。每个项目只有一个dll。您可以创建可重新分发的包和可重复的构建。您可以进行版本控制和构建脚本。

2）如果你在代码后面做了代码，你可以只上传一个dll。如果您更改了aspx，则可以上传aspx更改。

3）执行最多需要2-3秒。

4）整个项目在一个程序集中，这有助于引用任何页面或控件。结论。对于任何一种严肃的工作，你应该使用Web应用程序项目。特别感谢Rick Strahl在ASP.NET 2.0中的精彩文章Compilation and Deployment。

Answer 2

这对回滚很不利。如果你作为一个网站或网络应用部署，是的，你可以做一个或两个文件的快速补丁，但如果你需要回滚到以前的版本呢？祝你好运追踪所有更新的文件，以使新版本。由于组织原因，我更喜欢“版本”的概念，编译好的网络应用比“网站”项目更加内联。

Answer 3

我们遇到了这个困境，最终以编译版本为主，出于安全原因。如果你的站点是外部的，你可以通过允许vb文件以纯文本的形式存在，从而危及你的安全。我意识到，如果他们真的想要的话，仍然可以获得你的代码，但它会是一个额外的障碍，他们需要经历。如果您使用Visual Studio作为开发环境，则可以发布预编译的网站，并在发布时检查命名的程序集选项，这实际上会为每个aspx页面创建一个dll，以便您可以根据需要进行一次性更改。这是我们发现的一个很棒的功能，因为我们不断更新整个网站，有时候会更新不应该更新的内容。使用该功能后，我们不再有更新推送，不应该。至于回滚，我希望你使用某种类型的源代码控制/版本控制系统。 Team Foundation Server非常适合版本控制/源代码控制，但价格相当昂贵。

Answer 4

部署单个文件以进行错误修复和部署并不是明智的策略。这听起来像你需要一个全面的构建和部署过程。这并不意味着它必须变得复杂，因为现在有一些好的工具。

构建和部署可以得到详细的信息，因此最低限度尝试查看Microsoft Web Deployment Tool（http://www.iis.net/extensions/WebDeploymentTool）。在构建服务器上安装该工具并将其安装在部署服务器上。使用Visual Studio Publish命令在本地分级您的ASP.NET内容，然后使用上述工具同步部署服务器上的整个软件包。我喜欢这种方法，因为它可以完全自动化。在进行构建和部署时，要实现完全自动化以减少潜在的错误。

这是最低要求，但您至少要确定在特定文件发生更改时，它们在部署服务器上全部同步。

Answer 5

什么是最好的部署策略取决于你在什么样的环境中工作，以及你正在使用什么样的开发者。

与平面布局开始朝编程工作的视觉艺术家都在调整个人页面的生成和释放等等。另外.aspx.vb文件仅仅是服务器端脚本，而不是真正的编程。

程序员通常开始在命令行和分支出来的环境，如网络和理解的感觉良好的编程习惯应适用过的网页，包括标准测试和发布周期（和编译代码）。

如果该网站是在不断变化的各个页面会更有意义，但如果您需要提供安装包到生产组的MSI文件是要走的路，因为他们可以在需要时方便地备份出来。

如果您评价一下您的团体需求，包括人人小组中的丰富的经验，你应该能够说服用户可以自己或组。这不是一个更好的问题，但它提供了最好的商业模式。

Answer 6

我同意Rich。

更多信息：

1. 部署你的源代码阿拉的.vb文件到服务器是一个坏主意。编译它。如果可以混淆，只是不要部署直接来源。想象一下攻击者可以访问系统。他们可以很容易地改变你的代码，你可能没有注意到。是的，您可以使用反射器等工具进行反编译。但是，真正难以反编译完整站点，进行所需的更改并将其重新投入生产。

2. 部署一个单独的文件很可能会导致一些类型的问题相关的模块中。我猜你们真的没有做QA。告诉他们是时候长大了。

3. 编译你的网站会减少JIT（准时）编译。考虑表现。

4. 我也要去猜测，几乎每个人都拥有生产服务器的访问。从公司的角度来看，这是不好的，因为你没有控制权。当员工在离开前决定造成一些破坏时会发生什么？

5. 你所描述的是牛仔编码内联。当然，乘坐营救很有意思，但这种风格经常吹嘘一切。