【发布时间】：2008-11-08 18:50:35
【问题描述】：
通常，我们会在生产服务器上安装 VS.NET，以便在必要时轻松解决产品问题。
这是个好主意还是坏主意？
【问题讨论】：
标签： .net visual-studio-2008 visual-studio-2005 webserver
【发布时间】：2008-11-08 18:50:35
【问题描述】：
调试和开发应该在“安全”的环境中进行——这不是关键任务。例如，您应该有一个用于开发和调试的开发和/或 QA 服务器。
编辑：您的 QA 服务器应该镜像您的生产服务器，以便您能够在与您的生产环境相似（如果不相同）的环境中进行调试。
【讨论】：
-
我认为“如果不相同”是至关重要的，在这里。仅在一台服务器上发生的错误在我的世界中并不少见，原因根本上我无法控制。如果我的选择是使用 VS 或希望我可以在 QA 服务器上重现该错误，我将使用 VS。
-
但是 VS 不是你唯一的调试器。查看其他人关于在服务器上安装 Visual Studio 的替代方案的一些答案。
-
您仍然可以调试在生产服务器上运行的代码，而无需在服务器上安装 Visual Studio。查看远程调试器 (msdn.microsoft.com/en-us/library/bt727f1t.aspx)
-
我无法在我的生产服务器上使用远程调试器。我只能 RDC 进入服务器并在那里运行东西。我也许可以在服务器上安装并运行其他一些调试器，但为什么呢？顺便说一句，到目前为止我还没有在这个 prod 服务器上调试过，所以我没有在那里安装 VS。
-
我的意思是，显然您不想在生产服务器上安装和运行 VS。但是如果你必须这样做（有时你在现实世界中这样做），偷偷地环顾四周，然后继续去做。
这真的取决于你是否接受安装带来的风险：
- 当有人将调试器附加到错误的应用程序时，生产应用程序挂起。
- 它打破了被认为是最佳实践的做法，那么接下来您打算打破什么实践呢？在最坏的情况下，人们将开始在生产环境中执行开发任务
- 获得支持的潜在问题，如果安装了 VS 的生产环境支持 IIS 和 SQL Server 等，我会与 Microsoft 核实。
您还应该问自己，在没有 VS 的情况下在服务器上调试问题最困难的是什么：
- 你熟悉stack traces and how to read them吗？
- 您知道如何运行应用程序的调试模式版本与发布/免费版本吗？
- 您知道可以将SOS debugger extension 与Windows Debugging Tools 一起使用到.NET 应用程序吗？
- 您是否考虑过使用工具来自动收集和报告服务器崩溃？
- 您采取了哪些措施来防止生产中出现问题。您能否进行某种静态分析、根据问题重新设计模块或使用测试驱动开发之类的技术？
【讨论】：
这绝对不能接受。首先，对于调试，您始终可以使用 windows/windbg 的调试工具。也支持 .NET 调试（SOS / 罢工之子），并且使用备忘单并不难。 Windbg 无需安装即可从 U 盘运行。
第二，也是最主要原因：每当您安装任何较新版本的 VS 时，它都会将其调试器注册为交互模式** - 当发生异常时，您会收到一个消息框。您需要手动编辑注册表以在安装后恢复默认行为 - 没有人记得这一点。
不要这样做。有更好的方法来诊断问题。
【讨论】：
-
哇...这是什么？ :) 如何阻止这种情况发生，我从未见过，而且我现在确实在生产环境中安装了 VS.NET。
推荐的方法是拥有生产服务器的镜像用于测试/调试目的。要使镜像保持最新，您需要同时在两台服务器上安装所有应用程序更新，并在每晚或按需镜像上备份/恢复生产数据库。
仍然存在一些缺点，例如仅在重负载下才会发生的错误。在这种情况下，您需要某种日志记录来跟踪错误。此外，您可能需要购买额外的第三方组件许可证才能安装在生产镜像上。
【讨论】：
我认为这不是一个好主意。您的代码应该有足够的日志记录，以便如果生产中出现问题，您可以查看日志并确定发生了什么并在开发环境中修复它，然后在推送到生产之前在暂存/uat 环境中对其进行测试。
在我工作的地方，不允许开发人员访问由服务器/网络团队处理的任何生产环境，但那是因为它是一项大型业务。对于较小的公司，开发人员可以访问，但这并不意味着您应该将其用于调试。
【讨论】：
两者兼而有之。好处之一是它有时可以使诊断问题更容易。缺点之一是有时安装可能会破坏正在运行的 Web 应用程序。我只有在必要时才会这样做。
编辑：当同事决定在生产服务器上调试实时进程，在断点处停止应用程序，然后在没有意识到他已使应用程序不可用的情况下上床睡觉时，就会出现另一个潜在的缺点。是的，这发生在我身上。
【讨论】：
我永远不会直接在需要 Visual Studio 的生产服务器上做任何事情。对生产进行更改而不使其回到代码库并因此进入版本控制的风险太大。最终，您最终会重新引入一个您认为已经解决的错误，因为您只是在生产服务器上更改了它。偶尔我会在生产服务器上更新标记或 XML 文件，但只有在开发中做出更改并在 QA 机器上对其进行测试之后，并且只有在不涉及实际代码的情况下。
【讨论】：
当然，这取决于产品和您正在调试的内容。一般来说，您应该尽量避免它，但在某些情况下，您无法在测试服务器上完全复制场景，将调试器附加到正在运行的进程以快速缩小问题范围可能很有用。即，如果您正在运行 MMORPG 服务器，并且在某些负载条件下会出现间歇性错误，您可以花费数周或数月时间尝试从测试服务器上的日志文件和/或模拟连接中找出它，或者您可以附加问题在生产服务器上实时发生时的调试器，并在一个小时内解决。
不过，我倾向于将此视为一个例外情况，并尽可能合理地在生产服务器之外进行调试。
【讨论】：
在他的 blog 上查看 Sasha Goldshtein 的 Production Debugging 系列。他有一些很棒的演练和截屏视频，介绍了在没有 Visual Studio 的情况下可以进行哪些调试。
【讨论】：
取决于您如何使用它。它设计的大部分繁重的工作在生产服务器上都是不必要的。我通常在生产服务器上安装 Notepad++ 用于编辑 xml、配置文件等。我会说如果你想安装 VS，就去吧。
【讨论】：
-
我想他说的是用它来调试。 Notepad++ 不是很擅长。
在生产服务器上安装 Visual Studio 通常被认为不是“最佳实践”。这可能会带来安全风险——但我会担心的一个大问题是性能。 Visual Studio 使用大量资源，并且在那里运行调试会显着影响生产应用程序的性能。
【讨论】：