Действительно ли это безопасно и приемлемо установить VS.NET на Вашем рабочем сервере? [закрытый]

Это действительно зависит от того, принимаете ли Вы риск, что установка приносит с ним:

• Зависание производственных приложений, когда кто-то присоединяет отладчик к неправильному приложению.
• Это порывает с тем, что считают лучшей практикой, поэтому с какой практикой Вы собираетесь порвать затем? В худшем случае люди собираются быть тем, чтобы начинать сделать задачи разработки на производстве
• Потенциальные проблемы с получением поддерживают, я согласовал бы с Microsoft, если IIS и SQL Server и т.д. поддерживаются в продуктивной среде, где VS установлен.

Необходимо также спросить себя, что является самым трудным с отладкой проблемы без VS на сервере:

• Действительно ли Вы знакомы с отслеживаниями стека и как считать их?
• Вы знаете, как выполнить версию режима отладки приложения по сравнению с выпускать/освобождать сборкой?
• Знаете ли Вы, что можно использовать расширение отладчика SOS приложений.NET с Windows Debugging Tools?
• Вы рассмотрели использование инструментов, чтобы автоматически собраться и сообщить относительно катастрофических отказов сервера?
• Что Вы делаете для предотвращения проблем, происходящих в производстве. Можно ли сделать своего рода статический анализ, модули модернизации на основе проблем, или использовать ли технику как разработка через тестирование?

Это определенно не приемлемо. В первую очередь, для отладки Вас может всегда использовать средства отладки для windows/windbg. Поддержки.NET, отлаживающая также (SOS / сын забастовки), и со шпаргалкой, не являются этим трудно для использования. Windbg может работать от карты с интерфейсом USB без установки.

Во-вторых, и самая главная причина: каждый раз, когда Вы устанавливаете любую из более новых версий VS, он регистрирует свой отладчик для интерактивного режима ** - Вы получаете окно сообщения, когда исключение происходит. Необходимо вручную отредактировать реестр для возвращения назад к поведению по умолчанию после установки - и никто никогда не помнит это.

Не делайте этого. Существуют лучшие пути к диагностированию проблем.

Рекомендуется использовать зеркало рабочего сервера для тестирования / отладки. Чтобы поддерживать актуальность зеркала, вам необходимо устанавливать все обновления приложений одновременно на обоих серверах и выполнять резервное копирование / восстановление производственной базы данных на зеркале ночью или по требованию.

Есть некоторые недостатки, такие как ошибка, которая возникает только при большой нагрузке. В этом случае вам нужна какая-то регистрация для отслеживания ошибок. Также вам может понадобиться приобрести дополнительную лицензию сторонних компонентов для установки на рабочее зеркало.

I would not think this is a good idea. Your code should have sufficient logging so that if there is an issue in production you can go back through the logs and determine what has happened and fix it in a development environment, then test it in a staging/uat environment before being pushed to production.

At the place I work developers are not allowed access to any production environment, that is handled by the server/network teams but that is because it is a large business. For smaller firms the developers will have access but it doesn't mean you should use it for debuging.

Оба. Одним из преимуществ является то, что иногда это может облегчить диагностику проблем. Одним из недостатков является то, что иногда установка может сломать работающее веб-приложение. Я бы сделал это, только если бы мне пришлось.

Редактировать: еще один потенциальный недостаток этого происходит, когда сотрудник решает отладить живой процесс на рабочем сервере, останавливает приложение на точке останова, а затем ложится спать без понимая, что он оставил приложение недоступным. Да, это случилось со мной.

Я бы никогда не сделал прямо на рабочем сервере ничего, что требовало бы Visual Studio. Слишком рискованно вносить изменения в производство, которые не возвращают его в базу кода и, следовательно, в контроль версий. В конце концов, вы в конечном итоге вновь представите ошибку, которую, как вы думали, вы решили, потому что вы изменили ее только на рабочем сервере. Время от времени я буду обновлять файлы разметки или XML на рабочем сервере, но только после внесения изменений в разработку и проверки их в окне QA, и только тогда, когда не задействован какой-либо реальный код.

Взгляните на серию Production Debugging Sasha Goldshtein на его блоге. У него есть некоторые большие пошаговые демонстрации и скринкасты о том, что может быть сделано для отладки без Visual Studio.

Конечно, это зависит от продукта и того, что вы отлаживаете. Вообще говоря, вы должны стараться избегать этого, но в некоторых случаях вы не можете точно продублировать сценарий на тестовом сервере, и может быть полезно подключить отладчик к работающему процессу, чтобы быстро сузить проблему. то есть, если вы используете сервер MMORPG, и при определенных условиях нагрузки возникает периодически возникающая ошибка, вы можете потратить недели или месяцы, пытаясь выяснить это из файлов журнала и / или смоделированных соединений на тестовом сервере, или вы можете прикрепить отладчик, в то время как проблема возникает в реальном времени на производственном сервере, и выяснить это через час.

Я бы склонен рассматривать это как исключительный случай,

Зависит от того, как вы его используете. Большая часть тяжелой работы, для которой она предназначена, не должна быть необходимой на рабочем сервере. Я обычно устанавливаю Notepad ++ на рабочий сервер для редактирования XML, конфигурационных файлов и т. Д. Я бы сказал, что если вы хотите установить VS, сделайте это.

Это, как обычно полагают, не "Лучшая практика" для установки Visual Studio на рабочих серверах. Это может представить угрозы безопасности - но одно большое беспокойство, которое я имел бы, является производительностью. Visual Studio использует огромную сумму ресурсов, и выполнение Вашего отлаживания там может значительно повлиять на perforance производственных приложений.