Стоит ли прекомпилировать сайты ASP.NET 2.0 перед развертыванием или нет?

Question

Там, где я работаю, мы создаем очень большое количество очень маленьких приложений ASP.NET, и несколько раз случалось, что сайты были развернуты в предварительно скомпилированном формате, и приложение должно быть изменено, но версия кода Доступен в системе контроля версий, устарел, а разработчик недоступен. DLL-файл приложения должен быть декомпилирован и взломан вместе.

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

Каковы преимущества предварительной компиляции VS, загружающей файлы cs прямо на сервер и скомпилирующей их там?

Answer 1

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

Проблема, с которой вы сталкиваетесь, заключается не в прекомпиляции, а в компиляции при первом запуске. Вместо этого это связано с типом контроля источника, который вы используете. Если бы мне пришлось угадывать (и я делаю), я бы сказал, что вы используете Visual SourceSafe. Если бы вы переключились на систему управления исходным кодом, которая делала ветвление и слияние тривиальным, то вы могли бы разделить свой код на stable и development ветви. Исправления ошибок происходят в ветвях dev (которые затем проверяются обратно в ветвь stable). Таким образом, непроверенный или иным образом не готовый к прайм-тайму код не попадает на рабочий сервер, и у вас всегда есть копия stable, с которой можно работать.

Answer 2

Первое, что приходит в голову:

1. Вопросы коммерческой тайны
2. Проблемы безопасности
3. Неряшливый Джо Мо (Ленивый, Беспечный и Жалкий, хочу быть разработчиком)

4. Ad Hoc Взлом кода, который не контролируется.

   • Предварительно скомпилировано Код безопасно и эффективно выполняется на .Net Framework в управляемом формате.
   • UnCompiled Код развернут новичками, которым не потребовалось время, чтобы рассмотреть многие проблемы, связанные с небезопасным выполнением кода менее эффективно для конечного пользователя.

Конечные пользователи являются Держателями ставок и являются объектом Фидуциарных обязанностей разработчика . Разработчики должны использовать любую возможность для повышения эффективности своих продуктов.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ : Эти комментарии изложены "как есть", и мне наплевать, если вы будете проверять меня по буквам.

С уважением,

DrFunkie

Bad Speller, но чертовски хороший разработчик. :)

Answer 3

С точки зрения простоты использования, мне нравится просто загружать исходные файлы на сервер и забыть о предварительной компиляции.

Это то, что я делаю для всех сайтов, которыми я управляю, даже для крупных. Я стараюсь поработать над более важными частями приложения, чтобы убедиться, что все работает (и компилировать их, пока я в нем).

А вот еще одна мысль. Если сайт общедоступный, вы можете разрешить на нем проверку w3c link . Это будет иметь эффект компиляции каждой страницы, которую он посещает. И в любом случае это хорошая вещь, чтобы убедиться, что у вас нет битых ссылок.

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

Answer 4

Я загружаю файлы без предварительной компиляции: таким образом, так как мой код очень глючит, я могу исправить это с помощью Notepad ++ прямо с сервера

Кроме того, Visual Web Developer 2008 (бесплатный) не имеет опции компиляции: -P

Answer 5

Основным преимуществом является компиляция производительности на веб-сервере. Также он защищает ваш код, потому что код сложнее читать из сборки: -)

Answer 6

Это будет зависеть от размера приложений и частоты использования. Если он используется достаточно регулярно, чтобы пул приложений перерабатывался только в конце дня, может потребоваться краткое ожидание при первом запуске утром. Если он получает удар только раз в 30 минут, каждый раз вызывая перекомпиляцию, возможно, стоит прекомпилировать.

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