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

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

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

В чем преимущества предварительного компиляции VS файлов VS с загрузкой файлов непосредственно на сервер?

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

  • Торговые секреты
  • Проблемы безопасности
  • Sloppy Joe Moe (Lazy, Careless and Pitiful хочу быть разработчиком)

  • Ad Hoc Взлом кода, который вышел из-под контроля.

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

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

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

С уважением,

DrFunkie

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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