通常，我们会在生产服务器上安装VS.NET，以便在必要时使用我们的产品轻松解决问题。
这是一个好主意还是坏主意？
答案 0 :(得分：9)
调试和开发应该在“安全”环境中完成 - 这不是关键任务。例如，您应该有一个用于开发和调试的开发和/或QA服务器。
编辑：您的QA服务器应镜像您的生产服务器，以便您能够在与生产环境类似的环境中进行调试。
答案 1 :(得分：4)
这实际上取决于您是否接受安装带来的风险：
你应该问问自己，如果没有VS在服务器上调试问题，最困难的是：
答案 2 :(得分：4)
这绝对不可接受。首先，对于调试，您始终可以使用windows / windbg的调试工具。也支持.NET调试（SOS /罢工之子），并且使用备忘单并不难以使用。 Windbg可以在没有安装的情况下从USB记忆棒运行。
第二，也是最主要的原因：无论何时安装任何较新版本的VS，它都会将其调试器注册为交互模式** - 发生异常时会出现一个消息框。您需要手动编辑注册表以在安装后恢复为默认行为 - 并且没有人记住它。
不要这样做。有更好的方法来诊断问题。
答案 3 :(得分：3)
建议的方法是使用生产服务器的镜像进行测试/调试。要保持镜像最新，您需要同时在两台服务器上安装所有应用程序更新，并在每晚镜像或备份时备份/恢复生产数据库。
还有一些缺点，例如错误，只会在重负荷下发生。在这种情况下，您需要某种日志记录来跟踪错误。此外，您可能需要购买额外的第三方组件许可证才能在生产镜像上安装。
答案 4 :(得分：2)
我不认为这是个好主意。您的代码应该有足够的日志记录，以便在生产中出现问题时，您可以返回日志并确定发生了什么并在开发环境中修复它，然后在升级到生产之前在staging / uat环境中对其进行测试。
在我工作的地方，开发人员不允许访问由服务器/网络团队处理的任何生产环境，但这是因为它是一项大型企业。对于规模较小的公司，开发人员可以访问，但这并不意味着您应该将其用于调试。
答案 5 :(得分：1)
两者。其中一个好处是它有时可以使诊断问题更容易。缺点之一是有时安装可能会破坏正在运行的Web应用程序。我只会这样做。
编辑：当同事决定在生产服务器上调试实时进程，在断点上停止应用程序，然后上床睡觉而没有意识到他已经离开应用程序不可用时，会发生另一个潜在的缺点。是的，这发生在我身上。
答案 6 :(得分：1)
我永远不会在需要Visual Studio的生产服务器上直接做任何事情。对生产进行更改并不会使其重新进入代码库并因此进入版本控制风险太大。最终，您最终会重新引入一个您认为已解决的错误，因为您只在生产服务器上更改了它。有时我会更新生产服务器上的标记或XML文件，但只有在开发中进行了更改并在QA框中进行了测试之后，并且只有在没有涉及实际代码时才会更新。
答案 7 :(得分：1)
当然，这取决于产品和您正在调试的内容。一般来说，您应该尽量避免使用它，但在某些情况下，您无法在测试服务器上完全复制方案，将调试器附加到正在运行的进程以快速缩小问题范围可能很有用。即如果您正在运行MMORPG服务器，并且在某些负载条件下出现间歇性错误，您可能需要花费数周或数月的时间来尝试从测试服务器上的日志文件和/或模拟连接中找出它，或者您可以附加在生产服务器上实时发生问题时调试器，并在一小时内计算出来。
我倾向于将此视为一种例外情况，尽可能多地对生产服务器进行调试。
答案 8 :(得分：1)
在他的Production Debugging上查看Sasha Goldshtein的blog系列。他有一些很棒的演练和截屏视频，讲述了在没有Visual Studio的情况下可以进行调试的方法。
答案 9 :(得分：0)
取决于您如何使用它。在生产服务器上，大多数为其设计的繁重工作都不是必需的。我通常在生产服务器上安装Notepad ++来编辑xml，配置文件等。我想说如果你想安装VS，那就去吧。
答案 10 :(得分：0)
通常认为不是在生产服务器上安装Visual Studio的“最佳实践”。这可能会带来安全风险 - 但我担心的一个重要问题是性能。 Visual Studio使用大量资源并在那里运行您的debuging可以显着影响生产应用程序的执行。