logo标签列表

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

c#.netvb.netdeployment
6
我在一家维护一款相当新的应用程序的商店工作。该应用程序仍然存在许多错误，每天都会有大量的故障单。由于应用程序是在发布模式下编译的，我们得到的错误信息并不像可能那么有用（这很有道理）。
在将.NET应用程序部署到生产环境中时，是否有任何后果，如果它是在调试模式下编译的？我认为它可能会慢一些，但我已经读到差异是微不足道的。这将确保我们在收到故障单上的错误时，有与这些错误相关联的行号，这当然使调试更容易。
有什么主要的警告信号会阻止您这样做吗？我被委托研究这种可能性。所以感谢您的任何反馈。
6个回答
3

在调试模式下部署应用会降低性能。当然可以做出一些妥协。我建议采取以下方法之一:

1

你标记了[vb.net]，不能发布调试版本或使用WithEvents的程序。如果没有调试器附加，则已知并且似乎无法解决WeakReference实例的内存泄漏问题。它们用于支持Edit + Continue。

首先要做的是在应用程序中附带.pdb文件。在C# IDE中，使用Project + Properties，Build选项卡，高级选项中将Debug Info更改为“Full”。你会在异常堆栈跟踪中得到行号信息。

你不能完全信任行号，JIT优化器会移动代码以使其执行更快。还有像属性getter这样的内联短函数。你可以在可执行文件相同目录下添加一个yourapp.ini file来禁用JIT优化器。

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

我的经验是，如果你考虑的是桌面应用程序（winforms/WPF），这可能还可以工作，但绝不能尝试在asp.net应用程序中使用此方法。

0

这完全取决于您的生产环境、业务和性能要求的重要性。没有严格的规定。

我很感激您的反馈。我想在某种程度上，“这取决于情况”。老实说，我想尝试一下调试部署，看看是否会出现任何问题；然而，这个决定不在我的掌握之中。谢谢。 - Mario
0

部署调试版本对我来说是一个红旗，虽然这并不罕见。这是桌面应用程序还是服务器应用程序？任何调用Debug.Assert失败的情况都可能成为问题，因为这些可以关闭您的应用程序和/或导致调试器附加（VS.NET不是唯一的调试器，如果我回忆起来，.net fx安装了一个轻量级调试器）。虽然这对开发人员有帮助，但对普通人来说肯定会很困惑。

一个很好的选择是，而不是调试构建，确保您的错误报告机制包括（显示或记录）从任何抛出的异常中获取的堆栈跟踪信息。这可以很好地定位错误，而无需使用pdb。

1
断言应该总是向用户报告。如果一个断言失败了，那么应用程序中肯定出现了严重的问题，当然应该立即停止/崩溃。断言失败是测试期过短的结果，用户只应该看到异常（在“太阳花”世界中，是的，但是……）。 - Aurelien Ribon
很抱歉，我不同意用户应该看到断言。它们确实是测试时间太短的结果，但是不应向用户显示他们无法解决的错误消息。用户的目标不是知道“交易ID不能小于0”。断言对于帮助用户绝对没有任何作用。此外：断言在测试不充分的应用程序中经常出现且出现得令人意外。显示它们会削弱用户完成工作的能力，而对于开发人员来说，与良好记录的异常相比，它们只是略微更好的故障排除工具。 - dkackman
0
如果这是一个桌面应用程序，您可以尝试与一些客户一起使用，但请注意其他答案中给出的建议。尝试一些更有能力的用户或者那些遇到很多问题的人可能愿意自愿参与测试。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接