#asp.net #deployment #iis-6
#asp.net #развертывание #iis-6
Вопрос:
Ситуация такова, что я исправил незначительную ошибку в классе, поэтому они хотят просто развернуть затронутую библиотеку dll. Они остановили IIS, заменили DLL в папке / bin каталога iis для веб-сайта на новую, которую я им дал, и снова запустили iis. Есть несколько серверов, но они просто изменили ее на одном, чтобы опробовать. Они все еще видят ту же ошибку в журнале событий соответствующего сервера. Глядя на трассировку стека, я могу сказать, что на нем запущена старая библиотека dll.
Они проверили GAC и не видят ее там.
Я проверил dll с помощью reflector, чтобы убедиться, что я предоставил им правильную новую dll.
Это asp.net веб-сайт 2.0 и сервер 2003. Я не уверен, как она была развернута изначально, но у нее есть копия старой библиотеки dll в C:WindowsMicrosoft.NETFramework64v2.0.50727Temporary ASP.NET Files NAME_services################# сборка dl3################### и в D:xxxxSitesNAMEServicesobjRelease. Может ли это быть использование одного из них или сборка старого или даже просто кэширование его в памяти?
Комментарии:
1. Где была ошибка? Было ли это на страницах aspx или где-то в коде?
2. Это было в коде, я вижу исправление в сборке diss библиотеки dll.
Ответ №1:
Уничтожьте ваш временный asp.net содержимое папки. Не уверен, почему обновление не было скомпилировано автоматически.
Комментарии:
1. Автоматически ли компилируется такого рода развертывание? Если это так, то это может быть проблемой, поскольку они только что опубликовали библиотеку dll, а не исходный код.
2. @dwidel, иногда Asp.Net тупит и просто не копирует файлы во временную Asp.Net Папка Files. Удаление этого гарантирует, что оно разрешится само собой.
3. @dwidel НИКОГДА не размещал ваш исходный код на сервере. @Andy прав — это просто случается иногда. К счастью, это редко.
4. Это случается достаточно часто, чтобы вы могли также отключить свою временную папку как часть вашего сценария выпуска
Ответ №2:
У нас была такая же проблема, но с небольшими осложнениями, у нас много сайтов, поэтому «очистка всех временных параметров» и перезапуск IIS не являются для нас хорошим вариантом. Поэтому нам нужно было быть более избирательными в том, что принудительно обновлять.
На нашем компьютере контроля качества, под… «C:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Файлы «Я выполнил поиск в проводнике по частичному имени файла того, что мы пытаемся выпустить. Файл был найден в папке примерно такого типа: C:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Files root 4503212x ad95664x, поэтому я остановил app pool, удалил папку, перезапустил, и тогда все было развернуто — отлично!
Но…. У нас были те же проблемы с развертыванием в production, и вышеупомянутое не сработало.
Короче говоря, для пула приложений QA было установлено значение «включить 32-разрядную версию true», но для рабочей версии было установлено значение «False», поэтому временные файлы prod находились в: «C:WindowsMicrosoft.NETFramework64v4.0.30319 «вместо (Framework64 вместо Framework ).
Если очистка временных файлов не работает — дважды проверьте свои фреймворки или поищите файлы для обновления на C:WindowsMicrosoft.Уровень СЕТЕВОЙ папки и ниже. вы можете быть удивлены.
Комментарии:
1. Спасибо за это разъяснение. У нас был один веб-сайт, указывающий на Framework, а другой на Framework64.
Ответ №3:
Вам не нужно останавливать IIS для развертывания вашего обновления, вы просто копируете их.
Кроме того, если они скопировали только библиотеку DLL, но ваше исправление было в файле .aspx, то оно не будет отображаться. Вам действительно следует выполнить полное развертывание.
Комментарии:
1. Исправление определенно находится в dll, я могу использовать reflector, чтобы разобрать dll и посмотреть исправление.
2. Это не работает в удивительно большом количестве случаев. Это зависит от того, как было разработано приложение. IIS кэширует файлы, и иногда для этого требуется удалить временный файл.
Ответ №4:
Мы скопировали исходный код проекта в новую папку и повторно открыли решение. Это каким-то образом заставило Visual Studio не использовать кэшированную версию библиотеки DLL. Хотели бы мы знать, почему это сработало, но это решило проблему для нас.