![El mejor enfoque para implementar actualizaciones de archivos DLL en clientes Win7](https://rvso.com/image/658349/El%20mejor%20enfoque%20para%20implementar%20actualizaciones%20de%20archivos%20DLL%20en%20clientes%20Win7.png)
Estamos en un entorno de dominio Windows 7/Server 2008 R2. Tenemos una aplicación .NET con muchas bibliotecas internas para diferentes interfaces de usuario y otras funciones. Lo implementamos desde un recurso compartido donde se crea un directorio para cada "versión" con el número de versión más reciente. Ocasionalmente, hay algunos departamentos que necesitan modificar algo en la aplicación para sus necesidades específicas y necesitan el cambio con urgencia antes de la próxima versión. Podemos hacerlo dándoles una cierta cantidad de archivos DLL personalizados con los cambios solicitados en ellos. Estoy tratando de idear la forma más confiable y eficiente de hacer que nuestras máquinas cliente busquen y copie automáticamente estos archivos "personalizados". Quiero hacer esto de la manera más eficiente, confiable, administrada de manera centralizada y con la menor cantidad de gastos generales para los clientes. Preferiblemente, cuando tenemos archivos personalizados para implementar, nos gustaría que todos los clientes los copiaran dentro de las 24 horas posteriores a que los pusiéramos en el recurso compartido. Irían a una subcarpeta del directorio de versión de red actual, denominada "Personalizado" o algo similar. No tenemos SCCM en este momento, por lo que estoy analizando las siguientes opciones:
Script de inicio de sesión de archivos por lotes para usuarios que verificarán el directorio de red y copiarán (sobrescribirán) archivos locales usando robocopy o xcopy. Esto requeriría que el usuario cerrara la sesión y la volviera a iniciar, por lo que podría haber un retraso en la obtención de los archivos personalizados. Los usuarios tendrían una manera fácil y confiable de activarlo, lo que sería una ventaja.
Tarea programada configurada a través del elemento Preferencia de política de grupo, para verificar el directorio de red quizás varias veces al día en busca de archivos personalizados. Esto podría obtener el archivo más rápidamente que un script de inicio de sesión de usuario, pero no tengo experiencia con los elementos de tareas programadas de GPP. ¿Es confiable y sencillo de configurar y mantener? Nuevamente, esta tarea ejecutaría un script por lotes para buscar archivos en la red e iniciar la robocopia con la opción /xo. Si colocamos algún archivo en el directorio personalizado, asumiremos que es necesario, independientemente de las versiones. Simplemente verificar las fechas del archivo debería funcionar, para que no se vuelvan a copiar una y otra vez una vez que estén en su lugar.
Una tarea programada igual que la anterior, pero que se activa según una entrada del registro de eventos. ¿Es esto confiable? Nunca lo he probado. Podría ser ventajoso encontrar un desencadenante de evento que indique que la aplicación acaba de iniciarse (o cerrarse) y luego copiar los archivos de inmediato para que haya menos posibilidades de que se interrumpa el trabajo del usuario.
Sé que también hay un elemento de Preferencia de política de grupo para administrar/copiar archivos. Creo que sería demasiado trabajo administrarlo en este caso, porque podría haber varios archivos a la vez, en múltiples versiones de la aplicación.
También consideré un script de Powershell, que podría hacer cosas interesantes como comparar las versiones reales del archivo DLL, etc., pero esto probablemente requerirá más recursos (se ejecutará más lento) y realmente está haciendo más de lo necesario.
¿Alguna otra idea sobre lo que podría funcionar mejor? ¿Es la respuesta más simple (secuencia de comandos de inicio de sesión del usuario) realmente la mejor aquí?
Respuesta1
Terminé eligiendo la opción n.° 1, un script de inicio de sesión de usuario, y esto ha estado funcionando de manera confiable desde hace algún tiempo. Publicaría el script completo aquí, pero está lleno de detalles internos de la aplicación que lo harían prácticamente inútil para uso general. El detalle más interesante es que estamos usando wmic para obtener el número de versión interna de la aplicación instalada localmente y usándolo para referirnos al directorio de la versión correcta en nuestro servidor de implementación. Este código establece una variable denominada Versión para que coincida con el valor devuelto por 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"