Pregunta

Estoy trabajando en un proyecto implementado con ClickOnce, y estoy pasando por varios problemas.

Hay dos componentes en mi solución de software: un cliente de escritorio que necesita .NET Framework 3.5 para ejecutar, y un servidor ( ASP.NET ) que enumera los documentos disponibles y proporciona una forma de instalar el cliente de escritorio con ClickOnce.

Mi primer problema es el de los requisitos previos: necesito una forma de instalar el marco 3.5 antes de la instalación del cliente. Visual Studio crea un setup.exe que se encarga de eso, pero para que funcione, debe ejecutarse directamente (en lugar de vincularse al archivo .application ), y la implementación de URL debe conocerse al crear el manifiesto ClickOnce.

Entonces tengo dos problemas más: aparentemente no hay forma de ejecutar la aplicación cliente con argumentos de cadena de consulta después de instalarla con setup.exe , por lo que en lugar de tener un servidor que muestre la vinculación de la lista de documentos a una URL como " ... / client.application? document = doc1 " Solo puedo tener un enlace a setup.exe .

El otro problema es el peor: el servidor está destinado a ser utilizado en redes privadas relativamente pequeñas, y no en un solo servidor web. El problema es: no conozco la URL de implementación del cliente ClickOnce en el momento de la compilación, por lo que setup.exe no puede ejecutarse correctamente cuando la " instalación desde un sitio web " La opción está marcada. Por ahora, la solución consiste en tener un instalador sin conexión que contenga el setup.exe , los requisitos previos y los archivos de implementación ClickOnce en un archivo ZIP grande.

Un usuario con la versión de marco adecuada aún puede usar el enlace .application con la cadena de consulta al documento para instalar / actualizar el cliente y abrir el documento. Un usuario sin el marco recibe un mensaje de error ("La actualización del sistema requiere blablabla 3.5.0.0 blabla GAC"), y tiene que descargar el archivo ZIP, extraerlo en su máquina local y ejecutar el setup.exe archivo para instalar el marco, y luego el cliente. Y después de eso, tiene que volver a la lista de documentos y usar el enlace para iniciar el cliente con los argumentos adecuados.

No hace falta decir que no estoy muy orgulloso de esta estrategia, que arruina todas las ventajas de implementación de ClickOnce.

¿Es posible deshacerse del problema de requisitos previos de una manera más elegante? ¿Existe una manera simple de modificar la URL de instalación de la aplicación ClickOnce al implementar el servidor en una red (como escribir la URL en un archivo de configuración o algo así)?

¿Fue útil?

Solución

Yo también he estado tratando de resolver el "No sé la URL de implementación del cliente clickonce en el momento de la compilación". problema.

Lo mejor que puedo encontrar (acabo de comenzar a escribirlo, así que esto todavía es especulación) es escribir una utilidad que el usuario final ejecutará y establecerá el despliegue de URL. Esto parece ser posible en .NET pero necesita:

  • Leer en el manifiesto con ManifestReader.ReadManifest
  • establecer DeploymentUrl
  • ManifestWriter.WriteManifest

Luego debe firmar el manifiesto nuevamente utilizando SecurityUtilities.SignFile

El proceso de firma me molesta. O tengo que usar un certificado de usar y tirar (lo que hace que la firma no tenga sentido) o necesito usar un certificado de una CA y luego tengo que distribuir mi contraseña para renunciar al manifiesto (lo cual es estúpido ya que hace que mi certificado sea inseguro) . Así que me parece que el usuario está viendo "Editor desconocido" y un signo de exclamación amarillo ...

Otros consejos

Para compilar aplicaciones ClickOnce en nuestro sistema de compilación continua e implementarlas en varios servidores de prueba, pasé un tiempo con Mage y el artículo Tutorial: Implementar manualmente una aplicación ClickOnce .

No estoy seguro de si esto resolverá su segundo problema, pero al menos podría aliviar el proceso de compilación si implementa en varios servidores. Si puede distribuir mage.exe (no estoy seguro si Microsoft lo permite), puede modificar sus manifiestos en el sitio durante la instalación.

Quizás una solución sería:

Use PublishUrl = http: // clickonce / is / kinda / cool y en la computadora cliente alterar el archivo de hosts de Windows ubicado en
% windir% \ system32 \ drivers \ etc \ hosts y apunte el host una vez a la dirección IP fija del servidor .

Quizás ClickOnce debería tener una opción para detectar el servidor desde donde se descargó la aplicación; Si alguien sabe, publique aquí;

Si los usuarios están en un dominio, me gustaría que el administrador de sistemas expulse .NET 3.5 usando Políticas de grupo / Windows Update o cualquier otra estrategia que se utilice para administrar los escritorios.

Suena como un problema medioambiental. Si la organización es lo suficientemente grande como para tener un administrador del sistema, entonces debería ser responsabilidad de esa persona proporcionar un entorno para que se ejecute la aplicación.

Si la organización no tiene una persona en este puesto, entonces creo que ha vuelto a su solución manual. Además, hacerlo manualmente no necesariamente rompe 'todas las ventajas de ClickOnce' ... Las ventajas de ClickOnce es que puede modificar el cliente, volver a publicar y las máquinas cliente se actualizarán automáticamente ...

Supongo que la otra opción es escribir un script que obtenga e instale .NET 3.5 y luego instale la aplicación, no he hecho esto antes ... Estoy razonablemente seguro de que funcionará ... En realidad, usted podría implementar una secuencia de comandos de inicio a través de Políticas de grupo que también obtenga .NET 3.5, eso sería muy simple.

Quizás NAnt podría aprovecharse para automatizar el cambio de la URL de implementación. Lo uso para automatizar mis compilaciones de ClickOnce y cambiar la versión de compilación del manifiesto. ClickOnce con NAnt describe cómo Lo hice.

Segunda pregunta:

Puede usar el objetivo de publicación de MSBuild en un proyecto, solución o archivo MSBuild de la siguiente manera:

C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.exe "C:\path\foo.vbproj" /target:Publish /property:"PublishUrl=http://clickonce/is/kinda/cool/" /property:"PublishUrl=http://clickonce/is/kinda/cool/" 

PublishUrl es la ubicación donde se publicará la aplicación en el IDE. Se inserta en el manifiesto de la aplicación ClickOnce si no se especifica ni la propiedad InstallUrl ni UpdateUrl .

InstallUrl (no se muestra) es la ubicación desde donde los usuarios instalarán la aplicación. Si se especifica, este valor se graba en el programa de arranque setup.exe si la propiedad IsWebBootstrapper está habilitada. También se inserta en el manifiesto de la aplicación si no se especifica UpdateUrl .

Primera pregunta:

Si la respuesta anterior no se ocupa de sus necesidades, me parece que está enfrentando un problema típico; ¿Cómo se consigue un ejecutable de Windows (en su caso .NET Framework 3.5) instalado en varios escritorios? Existen múltiples soluciones como scripts de política de grupo (GP) o WMI .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top