当上传我的ASP.NET Web应用程序.dll文件到我的网站的/ bin /目录下,是有什么缺点使用调试版本,而不是重新编译发布版本。
例如,在网站上本地工作,构建配置设置为调试。 当事情看起来不错,我继续前进,上传最新的.dll文件的网站/ web应用。 如果我不是在这一点上切换构建配置为Release,然后编译,然后上传该版本的.dll文件到服务器?
我希望这个问题是不是重复。 我读了一些与主题类似的话其他的问题,但没有发现直接关系到我的问题的东西。
谢谢,
亚当
当上传我的ASP.NET Web应用程序.dll文件到我的网站的/ bin /目录下,是有什么缺点使用调试版本,而不是重新编译发布版本。
例如,在网站上本地工作,构建配置设置为调试。 当事情看起来不错,我继续前进,上传最新的.dll文件的网站/ web应用。 如果我不是在这一点上切换构建配置为Release,然后编译,然后上传该版本的.dll文件到服务器?
我希望这个问题是不是重复。 我读了一些与主题类似的话其他的问题,但没有发现直接关系到我的问题的东西。
谢谢,
亚当
与调试组件运行对性能重一点,因为它们占用更多的内存,但通常不是非常等等。 您应该仅部署时,它真的是一个“放”发布版本。 如果你仍然预期在野外意外的行为一定程度上,我会考虑使用调试组件,所以你会得到来自未处理的异常更多有用的信息。 真正的性能“疑难杂症”是指具有debug="true"
在你的web.config。
很多它取决于你个人的需求是什么。 在一般人不赞成把调试版本投入生产性能的原因。 所发射的调试代码显然不优化,包含可减慢代码的执行调试符号。
在另一方面,我工作的地方政策是把调试版本在生产,因为它可以很容易地看到行号等,当代码抛出异常。 我不是说我同意这个立场,但是我看到人们这样做。
Scott Hanselman在做调试和发布混合动力版,可以让你两全其美的好的帖子在这里 。
如果你有一个低容量的网站,你永远不会看到一个Debug组件的性能损失任何可测量的方式。 如果你有大容量,看看/日志记录等手段插装代码,而不是。
在高容量的网站,你需要进行大量的压力和负载测试非常努力它投入生产之前破坏应用程序。 我会做调试组件,其测试的第一阶段(因为你可能会打破的东西,它会更容易看到)。 然后,与发行组件重复,以确保他们的行为方式一样调试的。
http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx
应用很少会看到在释放和调试版本之间的性能差异显著。 如果你正在运行的中小型应用程序,你觉得可能是你还没有抓到任何错误,使用调试版本。