Кэшируют ли серверы Windows (2008) .NET-сборки?
У моего коллеги возникла следующая проблема (поэтому некоторые важные детали могут потребовать дополнительной проверки):
Сервер - Windows 2008 Server. Есть запущенная служба Windows (exe (.net), которая также использует сборку .NET). Есть ошибка с dll и / или exe. Некоторые отладочные сообщения были добавлены и удалены из библиотеки DLL. Эта новая версия библиотеки DLL и ее перекомпилированный exe были перенесены на этот сервер по ftp, служба была остановлена, существующие библиотеки DLL и exe были переименованы и заменены новыми, и служба запустилась.
Мы по-прежнему видим сообщения отладки, которые были удалены из библиотеки DLL. Их нет в новом коде.
Сервер был перезагружен.
Где-то кешируется старая dll? как-нибудь? Спасибо.
ОБНОВИТЬ
Только что произошло следующее:
- недавно переименованный файл assembly.old был физически удален (это была единственная копия)
- старые отладочные сообщения все еще там!
- служба удалена / переустановлена (хотя мы думаем, что могли бы обойтись без перезагрузки)
- работает.
Итак, зная, что произошло до этого (что включало перезапуск ОС) и что произошло сейчас, каким-то образом / каким-то образом Windows отслеживает DLL (?), И когда одна копия была переименована, Windows игнорирует обновление и связывает (в нем помните), что assembly.old будет assembly.dll. Не та новая сборка.dll, которую поставили на ее место?
Поскольку assembly.dll и assembly.old в одном каталоге, после перезапуска ОС постоянно смотрела старая dll. Assembly.dll и нет assembly.old - работает.
Что меня сбивает с толку, так это как вы это контролируете? Или где документация по этому поводу?
Прочая информация: 64-битная версия сервера. ВМ.
Это может быть связано с тем, как .NET находит сборки, описанные здесь:
Как среда выполнения .NET находит сборки
http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=VS.100%29.aspx
Обратите внимание на следующее:
«Компилятор записывает статические ссылки в метаданные манифеста сборки во время сборки. Динамические ссылки создаются« на лету »в результате вызова различных методов, таких как System.Reflection.Assembly.Load».
Если ваша ссылка статическая, вы можете проверить метаданные исполняемой сборки для манифеста. Манифест можно проверить с помощью ILDASM или другого инструмента, такого как ILSpy. Если он динамический, процесс определения местоположения сложен и изощрен.
По моему опыту, если существует несколько версий CLR (например, 2.0 и 4.0), результат может быть неожиданным. Есть несколько дополнительных факторов, таких как:
- конфигурация машины и конфигурация приложения;
- если приложение представляет собой полностью управляемый код или имеет некоторый неуправляемый код (COM / Interop);
- если выполняющаяся / вызывающая сборка и вызываемые сборки независимы от платформы («любой процессор») или зависят от платформы (x86 или x64).
Также можно одновременно запускать в процессе код CLR 2.0 и 4.0 (параллельное выполнение).
Я думаю, что это должно быть воспроизведено в среде разработки, и нереально ожидать, что потребитель будет знать или иметь дело со всеми возможными сценариями.
Параллельное выполнение внутри процесса .NET
http://msdn.microsoft.com/en-us/library/ee518876%28VS.100%29.aspx
Сборки: поиск, привязка и развертывание
http://www.codeproject.com/KB/install/assemblydeployment.aspx
Когда вы запускаете Process Explorer Microsoft SysInternals, выбираете сервисный процесс и вкладку .NET Assemblies, он должен показать вам все различные загруженные сборки, чтобы вы могли убедиться, что загружен правильный файл:
Ну вы ответили на свой вопрос там. Вы сбросили новую DLL на свой диск, но когда вы запускаете какой-то код, кажется, что он все еще использует старую DLL. Следовательно, где-то в вашей памяти должна быть копия старой DLL.
Попробуйте это - создайте ярлык и используйте его как команду для запуска:
% windir% \ system32 \ rundll32.exe advapi32.dll, ProcessIdleTasks
Назовите его как хотите ... что-нибудь вроде "Memory Cache Flusher". Запускайте его между тестовыми запусками вашей программы.