我查看了相关问题，但没有人提供我正在寻找的信息。
目前我工作的团队会对各个.aspx（和.aspx.vb）文件进行部署，以便修复错误/增强功能。我试图影响变化，因为我真的相信部署“整个编译站点”不容易出错。由于这是对事情进行的重大改变，我的建议已经遇到了重大阻力。
由于我的google-fu最近没有达到标准，我希望SO社区可以告诉我，我不在摇滚，并且移动单个文件没有任何问题，或者指向我真的良好的资源可以让我做出更强有力的案例。
修改
这一切都是很好的信息，并强化了我已经提出的论点，任何人都可以争论另一方吗？
答案 0 :(得分：2)
部署单个文件以进行错误修复和部署并不是明智的策略。听起来您需要全面的构建和部署过程。这并不意味着它必须复杂，因为现在有一些好的工具可供使用。
构建和部署可以得到详细信息，因此最低限度的开始尝试查看Microsoft Web部署工具（http://www.iis.net/extensions/WebDeploymentTool）。在构建服务器上安装该工具并将其安装在部署服务器上。使用Visual Studio Publish命令在本地暂存ASP.NET内容，然后使用上述工具同步部署服务器上的整个包。我喜欢这种方法，因为它可以完全自动化。在进行构建和部署时，旨在实现完全自动化以减少潜在错误。
这是最低限度，但您至少可以确定在更改特定文件时，它们在部署服务器上是全部同步的。
答案 1 :(得分：1)
我同意Rich。
更多信息：
将.vb文件的SOURCE代码部署到服务器是一个不错的主意。编译它。如果可以，请进行模糊处理，不要直接部署直接源。想象一下攻击者可以访问系统。他们可以轻松更改您的代码，您可能没有注意到。是的，您可以使用反射器等工具进行反编译。但是，对一个完整的网站进行反编译，进行所需的更改并将其重新投入生产真的很难。
部署单个文件可能会导致相关模块中出现某种类型的问题。我猜你们真的不做QA。告诉他们是时候成长了。
编译您的网站将减少JIT（及时）编译。想想表现。
我也猜测每个人都有生产服务器访问权限。从公司的角度来看，这是不好的，因为你没有控制措施。如果员工在离开前决定造成一些破坏，会发生什么？
您所描述的内容与牛仔编码相符。当然，骑车去救援很有趣，但这种风格经常会让一切都变得糟糕。
答案 2 :(得分：1)
你可以找到一个很好的详细比较here。我在这里复制这篇文章。
1）部署。如果您需要就地部署，这个模型是完美的。但是，由于您以明文形式公开逻辑，因此不建议使用它。因此，任何有权访问物理服务器的人都可能会弄乱您的代码而您永远不会注意到这一点。您可以尝试制作预编译的网站，但最终会得到很多dll和几乎不可触摸的aspx文件。 Microsoft认识到此限制并发布了Web部署项目工具。
2）您需要跟踪您在本地更改的内容以及上传到生产服务器的内容。没有版本控制。 Visual Studio具有Web Copy工具，但此工具无法提供帮助。我必须构建自己的工具，它根据Visual Source Safe跟踪变化。
3）当您按F5进行调试执行时，编译和执行整个项目仅需2分钟。当然，您可以将调试器附加到现有线程，但这不是一个明显的解决方案。
4）如果你试图在飞行中产生控制，你将会遇到第一个无法解决的限制。如何引用其他页面和控件。页面和控件编译基于每个目录进行。在最好的情况下，您将获得每个目录的程序集，最糟糕的是每个页面或控件将获得自己的程序集。如果您需要从控件或其他页面引用另一个页面，则需要使用@Reference指令显式导入它。
所以，
customControl = this.LoadControl（“〜/ Controls / CustomUserControl.ascx”）as 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编译和部署的精彩文章。
答案 3 :(得分：0)
回滚是不好的。如果您部署为网站与Web应用程序，是的，您可以快速修补一个或两个文件，但如果您需要回滚到以前的版本怎么办？祝你好运追踪所有已更新的文件以制作新版本。出于组织原因，我更喜欢“版本”的概念，而编译的Web应用程序与“网站”项目相比更加内联。
答案 4 :(得分：0)
我们遇到了这种困境，最终主要出于安全原因而使用编译版本。如果您的站点面向外部，则可以通过允许vb文件以纯文本格式存在来破坏您的安全性。我意识到如果他们真的想要，你仍然可以得到你的代码，但这将是他们需要经历的额外障碍。如果使用Visual Studio作为开发环境，则可以发布预编译的站点并在发布时检查命名程序集选项，这实际上将为每个aspx页面创建一个dll，以便您可以根据需要进行一次性更改。这是我们发现的一个很棒的功能，因为我们不断更新整个站点，有时候事情会得到更新而不应该更新。使用该功能后，我们不再需要推送更新。至于回滚，我希望你使用某种类型的源代码控制/版本控制系统。 Team Foundation Server非常适合版本控制/源代码控制，但价格相当昂贵。
答案 5 :(得分：-1)
最佳部署策略取决于您所处的环境类型以及您正在使用的开发人员类型。
以图形布局开始并致力于编程的视觉艺术家更加适应单个页面的生成和发布。此外，.aspx.vb文件只是服务器端脚本，而不是真正的编程。
程序员通常从命令行开始，并扩展到Web等环境，并且可以理解的是，应该在Web上应用良好的编程实践，包括标准的测试和发布周期（以及编译的代码）。
如果网站不断变化，各个页面会更有意义，但如果您需要向生产组提供安装包，则msi文件是可行的方法，因为如果需要，可以轻松退出。
如果您评估您的群体需求是什么，包括群体中每个人的不同体验，您应该能够说服自己或群体。这不是一个更好的问题，但它提供了最好的商业模式。