puede not microsoft ensamblado could common cargar archivo c# visual-studio deployment

c# - not - reportviewer exe



¿Cómo mantener el número de versión del instalador sincronizado con los números de versión de los ensamblajes instalados? (3)

CodeProject tiene una secuencia de comandos para establecer el número de versión de un archivo MSI, que puede ejecutar en el paso preconstruido del proyecto de instalación. Lo encuentras aquí:

http://www.codeproject.com/KB/install/NewSetupVersion.aspx

Más detalles

Tenga en cuenta que con Windows Installer las cosas son un poco más complicadas. Los archivos MSI (como el que crea utilizando un proyecto de configuración e implementación VS) no solo tienen un número de versión sino también un código de producto que es un valor GUID. Este código de producto es utilizado por Windows Installer para identificar de manera única su producto, por ejemplo, en el Panel de control -> Agregar o quitar programas donde puede decidir desinstalar o reparar un producto.

Sin embargo, al cambiar su número de versión de MSI, este código de producto también se debe cambiar en varios casos. La tecnología MSI está poco documentada, pero puede encontrar algunas recomendaciones sobre cuándo cambiar también el código del producto en la siguiente página de MSDN: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx .

En mis proyectos, siempre genero un nuevo código de producto para cada nueva versión. El script en CodeProject también cambiará el código del producto por usted.

Y una cosa más: Windows Installer solo verifica los primeros tres lugares del número de versión afaik, cualquier cosa en el cuarto lugar se ignorará, es decir, 2.3.0.1234 se considera igual a 2.3.0.5678. ( ProductVersion )

(Hay un artículo relacionado en CodeProject que también podría serle interesante: http://www.codeproject.com/KB/install/VersionVDProj.aspx )

En mi proyecto actual, estoy produciendo lanzamientos semanales. He estado usando la técnica que se describe en esta publicación para mantener sincronizados los números de versión de todos los ensamblados de mi proyecto. (En este momento, no tengo ninguna buena razón para rastrear los números de las versiones de los ensambles por separado, aunque estoy seguro de que ese día llegará).

Cuando lanzo un lanzamiento, construyo una nueva versión del instalador. A diferencia de todos los ensamblados, que pueden obtener sus números de versión de un archivo SolutionInfo.cs compartido, el número de versión del instalador no es, como puedo decir, una propiedad de ensamblado. Así que mi proceso de lanzamiento incluye avanzar manualmente el número de versión en el proyecto de instalación.

O, debería decir, generalmente incluye hacer eso. Me gustaría convertir eso en algo que no puedo arruinar. Estoy descubriendo que la documentación de los proyectos de configuración e implementación es sorprendentemente opaca (fue bastante más difícil averiguar cómo hacer para que la MSI se desinstale correctamente si el usuario la instaló en una ruta no predeterminada, que es un caso de uso común bastante maldito para ser indocumentado) y no tengo idea de si es posible hacerlo.

¿Algunas ideas?

Editar:

Solo para aclarar, este es un proyecto de configuración e implementación de Visual Studio del que estoy hablando.


Utilizo una solución para los proyectos de instalación de VS2010 (.MSI + setup.exe). Abra .vdproj en el Bloc de notas y edite el valor de asignación ProductVersion (3.2.1 en el ejemplo a continuación). Guarde el archivo e inicie VS2010 haciendo doble clic en el archivo .vdproj.

"Product" { "Name" = "8:Microsoft Visual Studio" "ProductName" = "..." ... "ProductVersion" = "8:3.2.1" "Manufacturer" = "..." ... }


Va a depender del juego de herramientas del instalador que está utilizando.

Usamos TFS Team Build y WiX v3 . Tengo una tarea de compilación personalizada que incrementa el número de compilación en Team build (5.0.0.X por ejemplo), luego este número de versión se envía al campo común AssemblyInfo.cs AssemblyFileVersion. También es transferido por MSBuild a nuestras soluciones / proyectos como una propiedad que luego pasa a WiX y se utiliza para actualizar también la versión del instalador.

Probablemente tengamos que mejorar un poco con las versiones de ensamblaje algún día también, pero en este momento esto ha funcionado bastante bien para nosotros.