.net 2.0 - ubicacion - ¿Puedo controlar la ubicación de la configuración de usuario de.NET para evitar perder configuraciones en la actualización de la aplicación?
porque se activa la ubicacion sola (4)
Estoy tratando de personalizar la ubicación del archivo user.config . Actualmente está almacenado con un hash y un número de versión
%AppData%/[CompanyName]/[ExeName]_Url_[some_hash]/[Version]/
Quiero que sea agnóstico a la versión de la aplicación
%AppData%/[CompanyName]/[ProductName]/
¿Se puede hacer esto y cómo? ¿Cuáles son las implicaciones? ¿El usuario perderá su configuración de la versión anterior después de la actualización?
(Agregaría esto como un comentario a la respuesta de @ Amr, pero aún no tengo suficientes representantes para hacerlo).
La http://msdn.microsoft.com/en-us/library/ms379611.aspx es muy clara y parece que todavía se aplica. Sin embargo, no menciona que el hash SHA1 está escrito en base 32 codificada, en lugar de la base 16 más típica.
Creo que el algoritmo que se utiliza se implementa en ToBase32StringSuitableForDirName , que se puede encontrar aquí en el origen de referencia de Microsoft .
El archivo user.config se almacena en
c:/Documents and Settings>/<username>/[Local Settings/]Application Data/<companyname>/<appdomainname>_<eid>_<hash>/<verison>
<c:/Documents and Settings> es el directorio de datos del usuario, ya sea no itinerante (Configuración local arriba) o en itinerancia.
<username> es el nombre de usuario.
<companyname> es el valor de 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, StrongName o Path, según la evidencia disponible para hash.
<hash> es un hash SHA1 de evidencia recopilada del CurrentDomain, en el siguiente orden de preferencia:
1. StrongName
2. URL:
Si ninguno de estos está disponible, use la ruta de acceso .exe.
<version> es la configuración AssemblyVersionAttribute de AssemblyInfo.
La descripción completa está aquí http://msdn.microsoft.com/en-us/library/ms379611.aspx
Para responder la primera pregunta, técnicamente puede colocar el archivo donde desee, sin embargo, tendrá que codificarlo usted mismo, ya que el lugar predeterminado al que va el archivo es el primero de sus dos ejemplos. ( enlace a cómo hacerlo usted mismo )
En cuanto a la segunda pregunta, depende de cómo implemente la aplicación. Si despliega a través de un .msi, entonces hay dos valores hash en las propiedades del proyecto de instalación (que está construido desde el msi), el ''código de actualización'' y el ''código del producto''. Estos determinan cómo se puede instalar msi, y si se actualiza, se sobrescribe o se instala junto a 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 de cuál sea su nombre. Sin embargo, si el código de ''actualización'' es el mismo, pero el código del ''producto'' es diferente, entonces cuando intente instalar el segundo msi le preguntará si desea actualizar, momento en el que se supone que debe copiar los valores del configuración anterior a una nueva configuración. Si ambos valores son los mismos, y el número de versión no cambió, 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 está basado más en la versión # de ClickOnce y en la ruta de la URL, sin embargo, he encontrado que mientras continúe ''Publicar'' en la misma ubicación, la nueva versión de la aplicación continuará usando el configuración existente ( enlace a cómo ClickOnce maneja las actualizaciones )
También sé que hay una forma de fusionar manualmente las configuraciones durante la instalación del msi usando scripts de instalación personalizados, pero no recuerdo los pasos exactos para hacerlo ... (vea this enlace para saber cómo hacerlo con una web). config)
Quería agregar este texto citado como referencia para cuando tenga este problema en el futuro. Supuestamente, puede indicar a la infraestructura de ApplicationSettings que copie la configuración de una versión anterior llamando a Upgrade :
Properties.Settings.Value.Upgrade();
Desde la publicación del blog de Preguntas frecuentes sobre la configuración del cliente :
P: ¿Por qué hay un número de versión en la ruta user.config? Si despliego una nueva versión de mi aplicación, ¿no perderá el usuario todas las configuraciones guardadas por la versión anterior?
R: Hay un par de razones por las cuales la ruta user.config es sensible a la versión.
(1) Para admitir la implementación paralela de diferentes versiones de una aplicación (puede hacerlo con Clickonce, por ejemplo). Es posible que diferentes versiones de la aplicación tengan configuraciones diferentes guardadas.
(2) Cuando actualiza una aplicación, la clase de configuración puede haberse alterado y es posible que no sea compatible con lo que se guardó, lo que puede ocasionar 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á configuraciones de la versión anterior que coincidan con la versión actual de la clase y las almacene 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: Bien, pero ¿cómo sé cuándo llamar a Upgrade?
A: 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 cargue la configuración. En los casos que no sean de Clickonce, no hay una actualización automática: debe realizar una actualización usted mismo. Aquí hay una idea para determinar cuándo llamar a la actualización:
Tener una configuración booleana llamada CallUpgrade y darle un valor predeterminado de verdadero. Cuando se inicia la aplicación, puede hacer algo como:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
Esto asegurará que Upgrade () se invoque 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 provea esta habilidad, pero el método es el mismo.