2010-11-03 11 views
8
  1. Tengo un proyecto de aplicación para Windows (a.exe) que llama a otro proyecto de biblioteca de clases (B.dll).configuración del proyecto no reemplaza archivos de ensamblaje

  2. A.exe tiene un botón (myButton) que llama al método Método1 desde B.dll.

  3. Para instalar la aplicación que creó un proyecto de instalación ASetup.vdproj, cuya salida principal es A.

  4. proyecto Después de compilar la configuración, la instalación ejecuta sin problemas , cuando a.exe inicia y I haga clic en myButton, la aplicación da sin error.

  5. Luego cambié B.dll y agregué un nuevo método Método2.

  6. myButton ahora llama a Method2 desde B.dll en lugar de Method1.

  7. que aumentó la versión de a.exe y incremento de la versión de ASetup.vdproj, pero no aumentan la versión de B.dll.

  8. Después de instalar la aplicación que cuenta que tenía dos instalaciones de a.exe en el Panel de control -> Agregar/quitar programas .

  9. Cuando se ejecuta a.exe y haga clic en myButton obtengo un error, "El método Método2 no se ha encontrado en B.dll", significa que la instalación no no reemplaza B.dll durante instalación.

  10. Ejecuté la desinstalación y noté que los archivos no se eliminaron del disco.

Mi pregunta es:

¿Por qué no actualización de la segunda instalación B.dll? Si la versión de B.dll se incrementa, B.dll se reemplazará durante la instalación, pero el problema es que mi proyecto actual tiene muchos ensamblajes externos, lo cual es difícil de controlar si se han modificado o no. Básicamente, lo que quiero es que todos los archivos de ensamblaje sean reemplazados en cada instalación.

Espero la opinión de todos ustedes. Gracias por toda la atención.

Respuesta

6

Las 2 entradas en Agregar o quitar programas me dicen que cambió la propiedad ProductCode pero no tenía una fila válida en la tabla de actualización para definir correctamente una actualización importante. MSI trata esto como 2 productos diferentes que se instalan en el mismo directorio. Cuando desinstala uno de los dos productos, los archivos permanecen hasta que desinstala el otro producto.

La DLL que no se sobrescribe me sugiere que no modificó el atributo AssemblyFileVersion de una compilación a otra. La primera instalación copia en 1.0.0.0 y la segunda instalación dice "1.0.0.0 ya está allí, no hay nada que hacer aquí" y se saltea.

2

Además del problema mencionado por @Christopher Painter, es muy probable que haya otro problema: el proyecto de instalación creado con Visual Studio (2008) solo reemplazará los archivos si se ha incrementado el número de versión. La solución obvia sería simplemente incrementar todos los números de versión; sin embargo, esto puede no ser siempre lo que quieres.

El comportamiento del archivo .msi está básicamente determinado por el momento en que se ejecuta la acción RemoveExistingProducts. Los instaladores creados con VS 2008 programan esta acción después de el nuevo producto ha sido instalado. Los ensambles modificados cuya versión no se ha incrementado por lo tanto no se reemplazan. se describen algunos detalles más sobre el comportamiento de actualización en este tema:

RemovePreviousVersions=True but previous version is not removed from the target machine

Para cambiar el comportamiento, puede parchear el archivo .msi creado hasta que se ejecuta la acción RemoveExistingProductsantes de la Se instala un producto nuevo (este ha sido el comportamiento si creó la configuración con Visual Studio 2005). Los parches pueden, p. hacer uso de una pequeña VBScript que se ejecuta como un paso de postas:

Dim objInstaller 
Dim objDatabase 
Dim objView 
Dim objResult 

Dim strPathMsi 

If WScript.Arguments.Count <> 1 Then 
    WScript.Echo "Usage: cscript fixRemovePreviousVersions.vbs <path to MSI>" 
    WScript.Quit -1 
End If 

strPathMsi = WScript.Arguments(0) 

Set objInstaller = CreateObject("WindowsInstaller.Installer") 
Set objDatabase = objInstaller.OpenDatabase(strPathMsi, 1) 
Set objView = objDatabase.OpenView("UPDATE InstallExecuteSequence SET Sequence=1450 WHERE Action='RemoveExistingProducts'") 

WScript.Echo "Patching install sequence: UPDATE InstallExecuteSequence SET Sequence=1450 WHERE Action='RemoveExistingProducts'" 
objView.Execute 
objDatabase.Commit 

WScript.Quit 0 
+1

He estado por ese camino con VDPROJ y en ningún momento se le hav de estos scripts postbuild docenas para moverse por el hecho de que VDPROJ apesta Volcado VDPROJ ahora para otra herramienta (WiX o IS 2010 LE) y tendrá una vida más larga. :-) Por cierto, el CM Expert en mí dice que es una locura enviar intencionalmente 2 MSI con diferentes ensamblajes que tienen la misma versión de archivo. La trazabilidad es crítica. –

+0

@Christopher Painter: Eso es todo muy cierto. –

+0

¿Cuál es el significado de este comando "SET Sequence = 1450"? ¿Hay alguna manera de ver la "base de datos" que supongo está integrada en el MSI en alguna parte? – Qwertie

Cuestiones relacionadas