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

就我个人而言,立即回退是最重要的。同样,网站项目在跟踪变化时非常困难。

你可以找到一个很好的详细比较 here

1) 部署。如果您需要就地部署,这个模型是完美的。但是,不建议这样做,因为您将以明文形式公开您的逻辑。所以,任何有权访问物理服务器的人都可能弄乱您的代码,您永远不会注意到这一点。您可以尝试创建预编译的web站点,但最终将得到大量dll和几乎不可接触的aspx文件。Microsoft认识到了这一限制,并发布了Web部署项目工具。

2) 您需要跟踪您在本地更改的内容以及您上传到生产服务器的内容。没有版本控制控件。VisualStudio有Web复制工具,但该工具没有帮助。我必须构建我自己的工具,该工具基于可视源安全跟踪更改。

所以呢,,

customControl=this.LoadControl(“~/Controls/CustomUserControl.ascx”)作为CustomUserControl;

但是如果你想动态地添加一些东西,却不能把所有合适的@Reference指令都放进去,那该怎么办呢?或者,如果您正在创建服务器控件,但它没有ascx文件,所以您没有@Reference的位置,该怎么办?因为每个控件都有自己的程序集,所以几乎不可能进行反射。

1) 部署。每个项目只有一个dll。您可以创建可再发行的包和可重复的生成。您可以拥有版本控制和生成脚本。

3) 执行最长需要2-3秒。

http://www.iis.net/extensions/WebDeploymentTool ). 在生成服务器上安装该工具,然后在部署服务器上安装。使用Visual Studio Publish命令在本地暂存ASP.NET内容,然后使用上述工具在部署服务器上同步整个包。我喜欢这种方法,因为它可以完全自动化。在进行构建和部署时,以完全自动化为目标,以减少潜在错误。

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

进一步资料:

1. 将源代码和.vb文件部署到服务器是个坏主意。编译它。如果可以,就不要直接部署源代码。想象一下,有一个攻击者获得了对系统的访问权。他们可以很容易地更改您的代码,而您可能永远不会注意到。是的,您可以使用reflector之类的工具进行反编译。但是反编译一个完整的站点,进行您想要的更改,并将其重新投入生产,确实很困难。

2. 部署单个文件很可能会在相关模块中导致某种类型的问题。我猜你们不是真的做QA。告诉他们该长大了。

3. 编译站点将减少JIT(即时)编译。想想性能。

4. 我还将猜测,几乎每个人都可以访问生产服务器。从公司的角度来看,这是不好的,因为你没有适当的控制措施。如果员工决定在离开前造成一些破坏,会发生什么?

我们遇到了这种困境,最终使用编译版本主要是出于安全原因。如果你的网站是面向外部的,你可能会因为允许vb文件以纯文本的形式存在而损害你的安全性。我意识到,如果他们真的想得到你的代码,他们仍然可以得到,但这将是他们需要克服的额外障碍。如果使用Visual Studio作为开发环境,则可以发布预编译的站点,并在发布时检查“命名程序集”选项,这将为每个aspx页面创建一个dll,以便在必要时进行一次性页面更改。这是一个伟大的功能,我们发现,因为我们不断更新整个网站,有时事情会得到更新,不应该。在使用该功能后,我们不再需要推送不应该推送的更新。至于回滚,我希望您使用某种类型的源代码控制/版本控制系统。Team Foundation服务器对于版本控制/源代码控制非常好,但价格相当昂贵。

程序员通常从命令行开始,扩展到web等环境,可以理解的是,良好的编程实践也应该应用于web,包括标准测试和发布周期(以及编译代码)。

如果站点处于不断变化的状态,那么单个页面会更有意义,但是如果需要向生产组交付安装包,msi文件是一个不错的选择,因为如果需要,可以很容易地将其备份。