我应该在部署之前预编译ASP.NET 2.0站点吗?

时间:2009-06-15 15:18:26

标签: asp.net deployment .net-2.0

在我工作的地方,我们做了非常多的非常小的ASP.NET应用程序,并且已经发生了几次以预编译格式部署网站,并且需要更改应用程序,但是代码的版本源代码管理中可用的已过期且开发人员不可用。该应用程序的DLL必须被反编译并一起被黑客入侵。

理想情况下,开发人员不会通过测试和生产来推动变更并跳过检查更改,我们已经对我们的策略进行了更改以防止这种情况发生,但我想知道编译网站的开销是否过高在应用程序池重新启动时在服务器上是一个足够大的问题,我们应该避免将代码直接上传到服务器。如果我们可以下载实时源,那么检查源代码管理中的版本与实际的实时版本会更容易。

预编译VS将cs文件直接上传到服务器并将其编译到那里有什么好处?

6 个答案:

答案 0 :(得分:8)

我不同意这一点给出的大部分答案。预编译通过临时发布文件有许多优点,其中最重要的是生产和测试环境中的代码或多或少保持同步。预编译可以确保您测试的代码是每隔时间生成的代码。

您遇到的问题不是预编译与首次运行编译之间的问题。相反,它源于您使用的源控件类型。如果我不得不猜测(我这样做),我会说你正在运行Visual SourceSafe。如果您要切换到使分支和合并变得微不足道的源控制系统,那么您可以将代码分成stabledevelopment分支。错误修复发生在dev分支上(一旦经过验证,就会合并回stable分支)。这样,未经测试或未准备好的黄金时间代码不会在生产服务器上结束,并且您始终可以使用stable集的副本。

答案 1 :(得分:2)

首先想到的是:

  1. 商业秘密问题
  2. 安全问题
  3. Sloppy Joe Moe(Lazy,Careless和Pitiful想成为开发人员)
  4. Ad Hoc Hacking the Code of the control of control。

    • 预编译代码以托管格式安全有效地在.Net Framework上运行。
    • 未编译代码由新手部署,他们没有花时间考虑与不安全代码相关的许多问题,这些问题对最终用户来说效率低下。
  5. 最终用户 利益相关者,是开发者信托责任的对象。 开发人员应该利用有机会提高产品的效率。

    免责声明:这些评论是“按原样”陈述的,如果您拼写检查我,我不会给出一个该死的。

    此致

    DrFunkie

    Bad Speller,但该死的好开发者。 :)

答案 2 :(得分:1)

从简单易用的角度来看,我只想将源文件上传到服务器而忘记预编译。

这就是我为所管理的所有网站所做的工作,即使是大网站。我确实习惯于点击应用程序中更重要的部分,以确保一切正常(并在我进行编译时编译它们)。

这是另一个想法。如果该网站是公开的,您可以将w3c link checker放在上面。这将具有编译它命中的每个页面的效果。无论如何要做到这一点是件好事,以确保您没有任何断开的链接。

简单地说,我认为这些例行检查几乎消除了用户首次访问编译速度慢的问题。因为无论如何这是一个很好的例程,它对我来说效果很好。

答案 3 :(得分:0)

这取决于应用程序的大小和使用频率。如果它被足够频繁地使用以至于应用程序池只在一天结束时被回收,那么在早上第一次启动时的短暂等待可能是值得的。如果它每30分钟才被击中一次,每次强制重新编译,那么可能值得进行预编译。

当然,如果它是一个非常大的应用程序,需要一段时间才能在第一次运行时进行编译,我会倾向于预编译,特别是如果它没有得到持续使用。

答案 4 :(得分:0)

主要优点是在网络服务器上编译性能。它也保护你的代码,因为从汇编中读取代码更难: - )

答案 5 :(得分:0)

我上传文件时没有预编译: 这样,由于我的代码非常错误,我可以直接从服务器使用Notepad ++来纠正它

此外,Visual Web Developer 2008(免费版)没有编译选项:-P