0
325
VisualizaçõesLa carpeta AppData/Local generada automáticamente se crea "incorrectamente"
cuando ejecuto un .net exe, se crea una carpeta correspondiente C:\Users\UserName\AppData\Local\AppName
dentro de esta carpeta, se crea otra carpeta AppName_Url_ABCXYZ
dentro de esta carpeta, se crea otra carpeta para la versión ensamblada de .net exe 0.2.28.0
¿Alguien puede explicar cómo Windows decide crear la carpeta de segundo nivel AppName_Url_ABCXYZ ?
tengo un problema cuando incremento mi versión de ensamblado y realizo una publicación de un solo archivo y ejecuto el exe resultante, se crea una nueva carpeta AppName_Url_ABCXYZ que contiene la nueva carpeta de versión de ensamblado.
esto causa problemas porque interrumpe la funcionalidad de Properties.Settings.Default.Upgrade() ya que la configuración para actualizar ya no está en el directorio esperado
Bien:
-AppData -Local -MyApp -MyApp_Url_ABCXYZ -0.2.13.0 -0.2.14.0 -0.2.15.0Malo:
-AppData -Local -MyApp -MyApp_Url_ABC1 -0.2.13.0 -MyApp_Url_ABC2 -0.2.14.0 -MyApp_Url_ABC3 -0.2.15.0 
Actualizar:
La información proporcionada por @Richard Deeming indica que la parte hash de la carpeta appdata se genera así:
var uri = "file:///" + fullExePath; //or 'assemblyName.CodeBase' if vshost (you can check the 'FriendlyName') uri = uri.ToUpperInvariant(); var ms = new MemoryStream(); var bSer = new BinaryFormatter(); bSer.Serialize(ms, uri); ms.Position = 0; var sha1 = new SHA1CryptoServiceProvider(); var hash = sha1.ComputeHash(ms); var hashstring = ToBase32StringSuitableForDirName(hash);lo que no tiene sentido ya que la ruta exe no está cambiando
este problema no ocurre con una nueva aplicación WPF .net 6 e incrementando la versión de ensamblaje, por lo que es algo específico de mi aplicación.
examinar los exe resultantes en el explorador de Windows no ayuda, parecen idénticos.
Actualizar:
No he podido determinar por qué ocurre esto en mi proyecto. Ni siquiera sé cómo depurarlo. Nunca he realizado ningún cambio intencional en este comportamiento.
2 Respostas
Responde à pergunta0
Descargue el paquete completo del proyecto aquí: ConsoleApp1.zip
Para demostrarlo, creemos una aplicación de consola simple:
y agregale un enlace:
<PackageReference Include="System.Configuration.ConfigurationManager" Version="6.0.0" />También agregaremos el archivo de propiedades del proyecto Settings.settings. Como resultado, obtenemos un proyecto con la siguiente configuración:
Después de compilar en modo de depuración y ejecutar el resultado de ConsoleApp1.exe, obtenemos la siguiente imagen en la ruta C:\Users\Administrator\AppData\Local\ConsoleApp1:
dentro de esta carpeta habrá una carpeta con el número de versión del programa:
Al compilar la versión de lanzamiento y ejecutar el resultado de ConsoleApp1.exe, obtenemos la siguiente imagen en la ruta C:\Users\Administrator\AppData\Local\ConsoleApp1:
dentro de esta nueva carpeta también habrá una carpeta con el número de versión del programa:
Cabe señalar que las versiones de depuración y lanzamiento del programa crean carpetas diferentes.
Cuando cambie la versión del proyecto, aparecerán nuevas versiones en las carpetas de depuración y lanzamiento, respectivamente:
Los programas de depuración y lanzamiento son "versiones" de compilación diferentes del mismo proyecto, y se crean URL diferentes para separarlos.
Descargue el paquete completo del proyecto aquí: ConsoleApp1.zip
0
Si mi entendimiento es correcto, la carpeta en cuestión ( C:\Users\UserName\AppData\Local\AppName\AppName_Url_ABCXYZ ) se usa para almacenar la configuración de user.config . Por favor revisa los siguientes hilos:
¿Cómo cambiar el directorio de configuración de usuario predefinido de mi aplicación .NET?
Ruta personalizada del usuario.config
Aquí está la cita de las preguntas frecuentes: https://docs.microsoft.com/en-us/archive/blogs/rprabhu/client-settings-faq
La ruta exacta de los archivos
user.configse parece a esto:
<Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.configdonde
<Profile Directory>: es el directorio de perfil móvil o el local. La configuración se almacena de forma predeterminada en el archivo local user.config. Para almacenar una configuración en el archivo roaming user.config, debe marcar la configuración con SettingsManageabilityAttribute con SettingsManageability establecido en Roaming.
<Company Name>: suele ser la cadena especificada por AssemblyCompanyAttribute (con la advertencia de que la cadena se escapa y se trunca según sea necesario, y si no se especifica en el ensamblado, tenemos un procedimiento alternativo).
<App Name>: suele ser la cadena especificada por AssemblyProductAttribute (las mismas advertencias que para el nombre de la empresa).
<Evidence Type>y<Evidence Hash>: información derivada de la evidencia del dominio de la aplicación para proporcionar un aislamiento adecuado del dominio de la aplicación y del ensamblado.
<Version>: normalmente, la versión especificada en AssemblyVersionAttribute. Esto es necesario para aislar diferentes versiones de la aplicación implementadas una al lado de la otra.El nombre del archivo siempre es simplemente
user.config.Si desea llegar a la ruta mediante programación, puede hacerlo mediante la API de administración de configuración (debe agregar una referencia a System.Configuration.dll).
El algoritmo de construcción de caminos tiene que cumplir ciertos requisitos rigurosos en términos de seguridad, aislamiento y robustez. Si bien tratamos de hacer que la ruta sea lo más fácil de descubrir posible mediante el uso de cadenas amigables proporcionadas por la aplicación, no es posible mantener la ruta totalmente simple sin encontrarse con problemas como colisiones con otras aplicaciones, suplantación de identidad, etc.
LocalFileSettingsProvider no proporciona una forma de cambiar los archivos en los que se almacenan las configuraciones. Tenga en cuenta que el proveedor en sí no determina las ubicaciones de los archivos de configuración en primer lugar, es el sistema de configuración. Si necesita almacenar la configuración en una ubicación diferente por algún motivo, la forma recomendada es escribir su propio SettingsProvider.
Parece que Microsoft intencionalmente no proporcionó la forma de configurar la ruta al archivo de configuración para evitar colisiones. Los subprocesos SO mencionados anteriormente parecen proporcionar algunas instrucciones sobre cómo implementar el SettingsProvider personalizado.
En su caso, la parte <Evidence Hash> es diferente después de actualizar la versión. Aquí hay un hilo más que describe la posible causa: https://social.msdn.microsoft.com/Forums/vstudio/en-US/d87a0add-00ba-4074-8ef3-cf085e1122eb/userscope-settings-path-changed-after-upgrade ?foro=netfxbcl
el hash de evidencia ha cambiado, porque estos valores se ven afectados por dos cosas, para obtener más detalles, consulte este enlace ,
1. Nombre fuerte
2.URL
Si ninguno de estos está disponible, use la ruta .exe.
<Evidence Type> puede ser la URL, el nombre seguro o la ruta, según la evidencia disponible para el hash. En la ruta en cuestión, puedo ver que se establece en Url. Como encontré en el libro "Programación de seguridad .NET", la evidencia de Url representa la URL desde la cual se cargó el ensamblaje. Si se cargó desde el disco, sería la URL file://. Sin embargo, no lo he comprobado con el ejemplo.
Probablemente, el cambio de URL o el cambio de ruta EXE afectaron el valor hash.
Además, es necesario comprobar si el nombre seguro del ensamblado ha cambiado.
Un nombre seguro consta de la identidad del ensamblado (su nombre de texto simple, número de versión e información cultural (si se proporciona), además de una clave pública y una firma digital. Se genera a partir de un archivo ensamblador utilizando la clave privada correspondiente. (El archivo de ensamblado contiene el manifiesto del ensamblado, que contiene los nombres y hashes de todos los archivos que componen el ensamblado). https://docs.microsoft.com/en-us/dotnet/standard/assembly/create-use- nombre fuerte