使用调试模式而不是发布模式将应用程序部署到生产？

我为一家维护相当新应用的商店工作。该应用程序仍然有其公平的份额，每天都有大量的门票。我们使用这些票据给出的错误信息并不像它可能是有用的，因为应用程序是以发布模式编译的，而我读的是更小更快的（有意义的）。使用调试模式而不是发布模式将应用程序部署到生产？

将.NET应用程序部署到在Debug模式下编译的生产是否存在任何后果？我希望它会慢一点，但我读过的区别是名义上的。这可以向我们保证，当我们在票证上发现错误时，我们有与这些错误相关联的行号，这当然会使调试变得更容易。

任何主要的红旗，会阻止你这样做？我负责研究这种可能性。所以感谢您的任何反馈。

来源

2010-10-28 Mario

在DEBUG而不是发布模式下部署您的应用程序会降低您的性能。当然可以做出妥协。我会建议下列之一：

看看你global.asax-
看类似一个妥协添加一个全局错误处理程序使用onerror建议由Scott Hanselman在

来源

2010-10-28 14:45:43 bechbd

这一切都取决于您的生产环境，业务和性能要求的重要性。没什么严格的。

来源

2010-10-28 14:42:09 Sheen

我很欣赏这个反馈。我肯定会想一些“它取决于”。我诚恳地想尝试调试部署，看看它是否会带来任何问题;然而，这个决定并不在我手中。谢谢。 – Mario 2010-10-30 21:11:02

部署调试版本对我来说是一个红旗，尽管它并不是前所未闻的。这是一个桌面或服务器应用程序？任何对Debug.Assert的调用失败都可能是一个问题，因为那些可以关闭你的应用程序和/或导致调试器附加（VS.NET不是唯一的调试器，如果我记得.net fx安装轻量级调试器）。虽然这对开发人员可能有所帮助，但它肯定会让普通人感到困惑。

运行良好的一个选项不是调试构建，可确保您的错误报告机制包含（显示或记录）来自任何抛出的堆栈跟踪信息exceptions。这有助于精确定位错误，而不需要pdbs。

来源

2010-10-28 14:44:52 dkackman

断言应该始终报告给用户。如果断言失败，那么应用程序中的某些内容是错误的，当然它应该立即停止/崩溃。断言失败是测试周期过短的结果，用户应该只会看到例外（在天线宝宝的世界里，是的，但是......）。 – 2010-10-28 14:50:34

恐怕我不同意用户应该看到断言。他们确实是测试过短的结果，但不应向用户显示他们无法做出的任何错误消息。知道“事务ID不能小于0”并不是用户的目标。一个断言对话框绝对0帮助用户。此外：断言在测试不当的应用程序中经常出现并出乎意料地出现。显示它们会降低用户完成工作的能力，同时对于开发人员来说只是一个更好的故障排除工具，而不是记录良好的异常。 – dkackman 2010-10-28 15:37:52

我的经验是，如果你想要一个桌面（winforms/WPF）应用程序，这可以工作正常，但在任何情况下你都不应该尝试使用asp.net应用程序。

来源

2010-10-28 14:45:45

您为此[vb.net]添加了标签，您无法发布使用WithEvents的调试版本或程序。如果没有附加调试器，则WeakReference实例中存在一个已知的和未解决的内存泄漏。它们用于支持编辑+继续。

您可以做的第一件事就是将.pdb文件与您的应用程序一起装运。在C＃IDE中使用Project + Properties，Build选项卡Advanced，将Debug Info更改为“Full”。您将在异常堆栈跟踪中获得行号信息。

您不能完全信任行号，JIT优化器会移动代码以使其执行速度更快。并内联短的函数，如属性获取器。您可以在同一目录下添加一个yourapp.ini file为禁用JIT优化

[.NET Framework Debugging Control] 
GenerateTrackingInfo=1 
AllowOptimize=0

来源

2010-10-28 15:34:44

如果这是一个桌面应用程序的可执行文件，你可以用几个客户尝试，但注意在其他的答案给出的建议。尝试更有权力的用户，或者有许多问题愿意自愿参加。

来源

2010-10-29 11:34:46 JeffO

使用调试模式而不是发布模式将应用程序部署到生产？

回答

相关问题