¿Puedo controlar la ubicación de la configuración del usuario de .NET para evitar perder la configuración al actualizar la aplicación?
Estoy intentando personalizar la ubicación del user.configarchivo. Actualmente está almacenado con un hash y un número de versión.
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
Quiero que sea independiente de la versión de la aplicación.
%AppData%\[CompanyName]\[ProductName]\
¿Se puede hacer esto y cómo? ¿Cuáles son las implicaciones? ¿Perderá el usuario la configuración de la versión anterior después de la actualización?
Quería agregar este texto citado como referencia para cuando tenga este problema en el futuro. Supuestamente puede indicarle a la infraestructura de ApplicationSettings que copie la configuración de una versión anterior llamando a Upgrade :
Properties.Settings.Value.Upgrade();
De la publicación del blog de preguntas frecuentes sobre configuración del cliente : ( archivo )
P: ¿Por qué hay un número de versión en la ruta user.config? Si implemento una nueva versión de mi aplicación, ¿el usuario no perderá todas las configuraciones guardadas en la versión anterior?
R: Hay un par de razones por las que la ruta user.config depende de la versión.
(1) Para admitir la implementación en paralelo de diferentes versiones de una aplicación (puede hacerlo con Clickonce, por ejemplo). Es posible que diferentes versiones de la aplicación tengan diferentes configuraciones guardadas.
(2) Cuando actualiza una aplicación, es posible que la clase de configuración se haya modificado y no sea compatible con lo que se guardó, lo que puede generar problemas.
Sin embargo, hemos facilitado la actualización de la configuración de una versión anterior de la aplicación a la más reciente. Simplemente llame a ApplicationSettingsBase.Upgrade() y recuperará las configuraciones de la versión anterior que coinciden con la versión actual de la clase y las almacenará en el archivo user.config de la versión actual. También tiene la opción de anular este comportamiento en su clase de configuración o en la implementación de su proveedor.
P: Está bien, pero ¿cómo sé cuándo debo llamar a Upgrade?
R: Buena pregunta. En Clickonce, cuando instala una nueva versión de su aplicación, ApplicationSettingsBase la detectará y actualizará automáticamente la configuración en el momento en que se carguen. En los casos que no son Clickonce, no hay actualización automática; debe llamar a Upgrade usted mismo. Aquí hay una idea para determinar cuándo llamar a Upgrade:
Tenga una configuración booleana llamada CallUpgrade y asígnele un valor predeterminado de verdadero. Cuando se inicia tu aplicación, puedes hacer algo como:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
Esto garantizará que se llame a Upgrade() solo la primera vez que se ejecuta la aplicación después de implementar una nueva versión.
No creo ni por un segundo que realmente pueda funcionar; no hay forma de que Microsoft proporcione esta capacidad, pero el método existe de todos modos.
Para responder a la primera pregunta, técnicamente puedes colocar el archivo donde quieras, sin embargo, tendrás que codificarlo tú mismo, ya que el lugar predeterminado al que va el archivo es el primero de tus dos ejemplos. ( enlace a cómo hacerlo usted mismo )
En cuanto a la segunda pregunta, depende de cómo implementes la aplicación. Si realiza la implementación a través de un .msi, entonces hay dos hashes en las propiedades del proyecto de instalación (a partir del cual se construye el msi), el 'código de actualización' y el 'código de producto'. Estos determinan cómo se puede instalar msi y si se actualiza, sobrescribe o se instala junto con cualquier otra versión de la misma aplicación.
Por ejemplo, si tiene dos versiones de su software y tienen diferentes códigos de "actualización", entonces para Windows son piezas de software completamente diferentes, independientemente del nombre. Sin embargo, si el código de 'actualización' es el mismo, pero el código de 'producto' es diferente, cuando intente instalar el segundo msi le preguntará si desea actualizar, momento en el cual se supone que debe copiar los valores del configuración antigua a una nueva configuración. Si ambos valores son iguales y el número de versión no cambió, entonces la nueva configuración estará en la misma ubicación que la configuración anterior y no tendrá que hacer nada. Documentación de MSDN
ClickOnce es un poco diferente, porque se basa más en el número de versión de ClickOnce y la ruta URL; sin embargo, descubrí que mientras continúe 'Publicar' en la misma ubicación, la nueva versión de la aplicación continuará usando la configuración existente. ( enlace a cómo ClickOnce maneja las actualizaciones )
También sé que hay una manera de fusionar configuraciones manualmente durante la instalación de msi usando scripts de instalación personalizados, pero no recuerdo los pasos exactos para hacerlo... (consulte este enlace para saber cómo hacerlo con un archivo web. configuración)
El archivo user.config se almacena en
C:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<version>
<C:\Documents and Settings>es el directorio de datos del usuario, ya sea sin roaming (Configuración local arriba) o roaming.
<username>es el nombre de usuario.
<companyname>es el valor CompanyNameAttribute, si está disponible. De lo contrario, ignore este elemento.
<appdomainname>es AppDomain.CurrentDomain.FriendlyName. Por lo general, el valor predeterminado es el nombre .exe.
<eid>es la URL, el nombre seguro o la ruta, según la evidencia disponible para el hash.
<hash>es un hash SHA1 de evidencia recopilada del dominio actual, en el siguiente orden de preferencia:
1. Nombre fuerte
2. URL:
si ninguno de estos está disponible, use la ruta .exe.
<version>es la configuración AssemblyVersionAttribute de AssemblyInfo.
La descripción completa está aquí http://msdn.microsoft.com/en-us/library/ms379611.aspx
(Agregaría esto como comentario a la respuesta de @Amr, pero todavía no tengo suficiente representante para hacerlo).
La información del artículo de MSDN es muy clara y parece seguir siendo válida. Sin embargo, no menciona que el hash SHA1 está escrito codificado en base 32, en lugar de la base 16 más típica.
Creo que el algoritmo que se utiliza está implementado en ToBase32StringSuitableForDirName, que se puede encontrar aquí en la fuente de referencia de Microsoft .
