visual studio publicar net chrome aplicacion c# .net deployment clickonce

c# - studio - publicar aplicacion windows forms



¿Cómo despliegue dos versiones de ClickOnce simultáneamente? (7)

Me gustaría tener la posibilidad de tener un servidor de prueba ClickOnce para mis aplicaciones donde los usuarios puedan ejecutar tanto la versión de producción como la versión de prueba en paralelo. es posible?

Primero intenté usar lo siguiente en AssemblyInfo.cs y también cambiar el nombre en la implementación de ClickOnce, aunque todo esto logrado fue sobrescribir la versión de producción de los usuarios con la versión de prueba. Del mismo modo, hizo lo mismo cuando volvieron al servidor de producción.

#if DEBUG [assembly: AssemblyTitle("Product Name - Test")] #else [assembly: AssemblyTitle("Product Name")] #endif

Pensé que también debería aclarar que las dos ubicaciones de implementación son diferentes entre sí y en servidores diferentes.

ACTUALIZAR

También he intentado configurar el GUID para el manifiesto dependiendo del modo de depuración, pero nuevamente no funciona (los GUID ficticios se usan a continuación).

#if DEBUG [assembly: Guid("AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA")] #else [assembly: Guid("BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB")] #endif

¿Cómo se distinguen los dos? Parece que el instalador los ve como dos programas separados cuando recibo una confirmación de instalación para cada uno. Sin embargo, cuando instalo el segundo, "Agregar / Quitar Programas" solo ve lo último, aunque el primero todavía está en el disco, ya que cuando lo reinstalo más tarde, simplemente se ejecuta, pero luego los modificadores de agregar / quitar programas De vuelta al nombre anterior.

Edité manualmente el .csproj para especificar un ProductName diferente para debug/release .

<PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Debug|AnyCPU'' "> ... <PublishUrl>publishbeta/</PublishUrl> <InstallUrl>http://www.softwareabc.com/download/beta/</InstallUrl> <ProductName>Software ABC Test</ProductName> <AssemblyName>SoftABCTest</AssemblyName> <ApplicationIcon>Resources/Test.ico</ApplicationIcon> </PropertyGroup> <PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Release|AnyCPU'' "> ... <PublishUrl>publish/</PublishUrl> <InstallUrl>http://www.softwareabc.com/download/</InstallUrl> <ProductName>Software ABC</ProductName> <AssemblyName>SoftABC</AssemblyName> <ApplicationIcon>Resources/Application.ico</ApplicationIcon> </PropertyGroup>

Una advertencia es que Visual Studio 2010 no actualiza esto si cambias entre debug / release. Solo surte efecto cuando carga la solución, así que asegúrese de cambiar debug / release, luego cierre y vuelva a abrir la solución.

Intente cambiar el nombre del ensamblaje en la pestaña Aplicación en la ventana de propiedades.

Lo hago todo el tiempo. Incluso tengo una pantalla en mi aplicación que cambia la versión que obtendrá un usuario específico. Y no estoy haciendo nada complicado por el lado de la aplicación, toda la magia está en el servidor web que aloja los archivos ClickOnce.

Eche un vistazo al artículo que escribió mi amigo, Versiones de grano fino con ClickOnce . Explica cómo lo hicimos.

Puede sonar un poco cojo, pero la forma más sencilla de hacerlo es tener dos proyectos EXE en su solución. El método Main de cada uno de estos solo llamará al método Main en su proyecto EXE original (que habrá cambiado a un archivo DLL).

Esto significa que cada proyecto EXE puede tener su propia configuración de publicación ClickOnce, así como su propio archivo app.config . Esto significa que tiene diferentes cadenas de conexión para la producción y la versión de prueba.

Su otra opción (la que podría parecer más sensata) es usar MageUI.exe para crear manualmente los archivos ClickOnce, que le permitirían elegir un archivo de configuración diferente y una ubicación de publicación cada vez que ejecute la herramienta. También hay una versión de línea de comandos (Mage.exe), por lo que en teoría podría automatizar esto.

Sin embargo, encontramos que la solución con dos proyectos "runner" era mucho más simple. Te recomiendo que pruebes eso primero.

Una variación del escenario de dos proyectos de Peter Mortensen. Quería dev, prueba de cliente y lanzamiento de cliente. En mi caso, quería que la prueba del cliente proporcionara algunas pistas visuales de que era de prueba, no en vivo (por ejemplo, "PRUEBA" en el título y un tema visual diferente).

Me pareció más simple tener dos soluciones y dos proyectos de stub. Cada proyecto en su propio directorio, con su propio programa auxiliar de programación de código auxiliar, aplicación.config y assemblyinfo.cs.

En la solución dev / test, la configuración de depuración fue para dev, la configuración de la versión fue para la prueba del cliente. Utilicé SlowCheetah para transformar el app.config para este último.

En la solución de lanzamiento del cliente solo necesitaba una configuración de lanzamiento.