visual-studio-2010 - para - visual studio code español

El instalador no sobrescribirá la aplicación existente (8)

Al refinar un poco las respuestas, debe incrementar la versión del archivo para que Windows Installer se sobrescriba durante una actualización. Esto no es necesariamente lo mismo que incrementar la versión de ensamblaje como algunos lo han indicado. Solo la versión del archivo necesita incrementarse, y con el código administrado puede hacerlo con AssemblyFileVersion. La versión del archivo es predeterminada para la versión de ensamblaje, pero AssemblyFileVersion le permite hacerlos diferentes cuando tiene ensamblados de cliente que dependen de una AssemblyFileVersion específica.

Tengo una solución de Visual Studio 2010 con 8 proyectos. También tiene un proyecto de instalación que construyo para crear la instalación.

Funciona bien cuando es la primera instalación en una PC cliente. Sin embargo, luego modifico mi proyecto, construyo una nueva configuración y la paso a los clientes. Cuando esto sucede, el cliente debe primero, manualmente, desinstalar la última instalación y luego ejecutar la configuración.

Si ejecutan la configuración, sin desinstalarla, parece que no sobrescribe los archivos existentes (exe y dlls). Por lo general, es sólo el exe que se modifica. Sin embargo, no lo sobrescribe. La versión en la máquina cliente parece permanecer igual.

¿Hay alguna forma de forzarlo a sobrescribir?

Tenga en cuenta que cuando modifico el proyecto de mi aplicación principal, voy a las propiedades del proyecto, a la información de ensamblaje y aumente la Versión de ensamblaje y la Versión de archivo.

El instalador de Visual Studio no es el más fácil de usar en comparación con los productos comerciales o incluso con WiX si busca un buen nivel de control sobre su instalación.

Cuando tiene un proyecto de instalación de Visual Studio, tiene varias propiedades involucradas en el proceso de actualización

1) El Código de actualización: este es el enlace entre instaladores de la misma clase y no debe cambiar este código innecesariamente

2) El número de la versión: extrañamente, solo se usan los primeros 3 números (major.minor.build) para la comparación (este es un error común que muchos desarrolladores cometen)

3) El código del producto: tan pronto como cambie el número de versión, VS le solicitará que cambie este número; hágalo; si automatiza el cambio de número, recuerde hacerlo también.

4) DetectNewerInstalledVersion: se establece en True

5) RemovePreviousVersions - establecer en True

Personalmente, buscaría usar WiX para una instalación tan pequeña, es decir, si puede hacerlo en Visual Studio, entonces la versión de WiX

Mi instalador para OpenCover se ve así

Espero que encuentres lo anterior útil

En las propiedades del proyecto de instalación, cambie los números de versión / compilación. Esto le pedirá que permita que se genere un nuevo GUID. Al hacerlo, se le indica al instalador que tiene una nueva versión y permitirá que la versión anterior del programa se elimine automáticamente y la nueva sea instalada por el sistema MSI.

Esta es una publicación antigua, pero se agrega a las personas que podrían venir en busca de una respuesta.

Me encontré con este mismo problema, incluso después de seguir todo lo que se da here a la carta. Mi problema fue que la versión del programa C # no se incrementará en cada compilación sin importar qué. Incluso después de editar manualmente AssemblyInfo.cs, la versión del exe generado aún sería 1.0.0.0. Como resultado, la instalación no reemplazará el archivo.

La solución es agregar una condición de inicio al nodo "Resultado principal del proyecto XYZ" (o lo que sea que desee sobrescribir) del proyecto de configuración. Esto hace que el instalador elimine el archivo cuando se ejecuta la configuración más reciente. Ahora, cuando el usuario inicia la aplicación, aparece una ventana que indica que la aplicación se está configurando, los archivos más nuevos se copian en la carpeta de la aplicación y se inicia la aplicación. Esto es simple prueba y error. No tengo ni idea de por qué funciona de esta manera (y necesito algo de café después de pasar toda la noche tratando de resolver esto :)).

Haga clic derecho en su proyecto de configuración >> Ver >> Condiciones de lanzamiento
Haga clic derecho en "Requisitos en la máquina de destino" >> Agregar condición de lanzamiento de archivo
Aparecerá un nodo ("Buscar archivo1") en "Buscar en la máquina de destino" y otro nodo ("Condición1") aparecerá en "Condiciones de lanzamiento"
Haga clic en Buscar archivo1 y cambie su propiedad de Nombre de archivo a algo que está destinado a preexistir (como "Notepad.exe", bueno, casi siempre)
Tenga en cuenta que "Carpeta" está configurada en "[SystemFolder]" y "Propiedad" está configurada en "FILEEXISTS1"
Ahora haga clic en Resultado principal de XYZ Project o en cualquier otro nodo y, en la ventana de propiedades, establezca "Condición" en "FILEEXISTS1" exactamente como apareció arriba

También tuve el problema de que el archivo .exe no se actualizaba aunque seguí los pasos anteriores. Parece que la versión del producto del archivo .exe no sigue automáticamente el número de versión establecido en las propiedades de configuración. Para que el .exe sea reemplazado al ejecutar los nuevos instaladores, incremente la versión del producto de la siguiente manera:

1) Ir a Propiedades del proyecto> Aplicación> Información de ensamblaje ...

2) Aumentar los números de versión de montaje y archivo

3) Vuelva a crear la configuración y la instalación debería sobrescribir el antiguo .exe

Espero que esto ayude a alguien.

Tuvo problemas similares con archivos que no sobrescribieron. Números de versión verificados, códigos de producto / actualización, todo. Lo que finalmente me ayudó fue esta publicación en MSDN . Específicamente la parte aquí, cuando se usa Orca para examinar el archivo msi:

También cambié la secuencia de RemoveExistingProducts en la tabla> InstallExecuteSequence de 6550 a 1525 (después de InstallExecute hasta después de> InstallInitialize).

No estoy seguro de por qué, pero el instalador parece ejecutar la desinstalación de la versión anterior después de que ya haya instalado la nueva versión. Tal vez haya una razón para ello, pero cambiarlo parecía ser la única forma en que podía forzar la actualización de mi aplicación.

Si alguien más se topa con este problema como lo he hecho recientemente, espero que esta solución le ayude.

Yo tuve el mismo problema. La mejor manera de asegurarse de esto es asegurarse de que su archivo ejecutable, es decir, el propio Application.exe tiene una versión más alta que la anterior.

Simplemente haga clic en las propiedades del proyecto (no en el proyecto de configuración) y configure la versión de la aplicación en una más alta.

AssemblyVersion & AssemblyFileVersion debe incrementarse para sobrescribir el ensamblado (exe / dll) junto con otras configuraciones, lo que @shaun wilde mencionó