![Лучший подход к развертыванию обновлений DLL-файлов на клиентах Win7](https://rvso.com/image/658349/%D0%9B%D1%83%D1%87%D1%88%D0%B8%D0%B9%20%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%20%D0%BA%20%D1%80%D0%B0%D0%B7%D0%B2%D0%B5%D1%80%D1%82%D1%8B%D0%B2%D0%B0%D0%BD%D0%B8%D1%8E%20%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9%20DLL-%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%20%D0%BD%D0%B0%20%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B0%D1%85%20Win7.png)
Мы находимся в доменной среде Windows 7 / Server 2008 R2. У нас есть приложение .NET с большим количеством внутренних библиотек для различных пользовательских интерфейсов и других функций. Мы развертываем его из общего ресурса, где для каждого «релиза» создается каталог с последним номером версии. Иногда есть некоторые отделы, которым нужно что-то подправить в приложении для их конкретных нужд, и им нужно срочно внести изменения перед следующим релизом. Мы можем сделать это, предоставив им некоторое количество пользовательских файлов DLL с запрошенными изменениями в них. Я пытаюсь разработать наиболее надежный и эффективный способ, чтобы наши клиентские машины автоматически проверяли и копировали эти «пользовательские» файлы. Я хочу сделать это наиболее эффективным, надежным, централизованно управляемым способом и с наименьшими накладными расходами для клиентов. Предпочтительно, когда у нас есть пользовательские файлы для развертывания, мы хотели бы, чтобы все клиенты копировали их в течение 24 часов после того, как мы поместим их в общий ресурс. Они будут находиться в подпапке текущего сетевого каталога релиза, названной «Пользовательский» или как-то похоже. На данный момент у нас нет SCCM, поэтому я рассматриваю следующие варианты:
Пакетный файл сценария входа для пользователей, который будет проверять сетевой каталог и копировать (перезаписывать) локальные файлы с помощью robocopy или xcopy. Это потребует от пользователя выхода из системы и повторного входа, поэтому может возникнуть задержка в получении любых пользовательских файлов. У пользователей будет простой и надежный способ запустить его, что будет плюсом.
Запланированная задача, настроенная через элемент Group Policy Preference, для проверки сетевого каталога, возможно, несколько раз в день на наличие пользовательских файлов. Это может получить файл быстрее, чем сценарий входа пользователя, но у меня нет опыта работы с элементами GPP Scheduled Task. Является ли она надежной и простой в настройке и обслуживании? Опять же, эта задача запустит пакетный сценарий для проверки файлов в сети и запустит robocopy с параметром /xo. Если мы поместим какие-либо файлы в пользовательский каталог, мы предположим, что они нужны, независимо от версий. Простая проверка дат файлов должна сработать, поэтому они не будут повторно копироваться снова и снова, как только окажутся на месте.
Запланированная задача, та же, что и выше, но запускаемая на основе записи журнала событий. Надежно ли это? Я никогда не пробовал. Может быть полезно найти триггер события, который указывал бы, что приложение было только что запущено (или закрыто), а затем сразу же скопировать файлы, чтобы уменьшить вероятность прерывания работы пользователя.
Я знаю, что есть также элемент Group Policy Preference для управления/копирования файлов. Я считаю, что в этом случае это будет слишком большой работой, поскольку может быть потенциал для нескольких файлов одновременно, в нескольких версиях приложения.
Я также рассматривал скрипт Powershell, который мог бы делать интересные вещи, например, сравнивать фактические версии DLL-файлов и т. д., но это, вероятно, потребует больше ресурсов (будет работать медленнее) и на самом деле делает больше, чем нужно.
Есть еще идеи, что может сработать лучше всего? Действительно ли самый простой ответ (скрипт входа пользователя) здесь лучший?
решение1
Я в итоге выбрал вариант № 1, скрипт входа пользователя, и он надежно работает уже некоторое время. Я бы опубликовал весь скрипт здесь, но он полон внутренних деталей приложения, которые делают его практически бесполезным для общего использования. Самая интересная деталь заключается в том, что мы используем wmic для получения внутреннего номера версии локально установленного приложения и используем его для ссылки на правильный каталог версий на нашем сервере развертывания. Этот код устанавливает переменную с именем Version для соответствия значению, возвращаемому wmic.exe
set "myfile=c:\\progra~2\\%AppFolder%\\AppName.exe"
for /f "tokens=*" %%f in ('wmic datafile where "name='%myfile%'" get version /value ^| findstr "="') do set "%%f"