Application.UserAppDatapath Strange Comportamento

Question

Quando utilizzo Application.UserAppDatapath per ottenere configurazioni, ho un argomentoException "Caratteri illegali nel percorso". Secondo Microsoft IT è Non un bug, ma una caratteristica;

.

L'unico modo in cui è possibile ottenere un carattere illegale in FileRersionINFO.ProductVersion (e quindi in application.Productversion e Application.USERAPPDataPath) è quando hai anche assemblyFileVersion sull'assemblea. Il valore che va a AssemblyFileVersion viene copiato sulle risorse Win32 Verbatim e sovrascrive il valore che passa alla AssemblyVersion. Questo comportamento è di design.

Allora commentando [Assembly: AssemblyFileVersion ("...")] In AssemblyFo.CS Si potrebbe risolvere questa eccezione.

Il problema è : Sto scrivendo un po '.dll con controlli winforms. Il design più semplice per ottenere questo percorso sarebbe quello di usare application.UserAppDatapath. Ma se application.UserAppDatapath viene utilizzato, gli sviluppatori che utilizzano questa libreria non possono avere assemblyFileVersion per i loro file .exe. (Mentre AssemblyFileVersion è nell'assembleaNFo.cs per impostazione predefinita)

Inoltre non sono riuscito a trovare alcuna informazione da Microsoft che l'utilizzo di AssemblyFileVersion dovrebbe frenare la mia applicazione e qualcuno non dovrebbe usarlo. Quindi, in realtà, non posso chiederlo da questo utente della biblioteca.

C'è una ragione o una logica in una situazione così strana? Qual è un migliore lavoro per ottenere l'applicazione. Percorso di ApplicationAppDatapath senza tali problemi?

Mentre ho assemblyFileVersion e Application.UserAppDataPath lancia l'eccezione, l'applicazione funziona e potrei ottenere questo percorso attraverso

string path = ConfigurationManager.OpenExeConfiguration(
            ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;

.

I file di configurazione sono lì e non hanno problemi. Ma certamente, è un modo brutto.

Answer 1

Se leggo quel post su Connetti correttamente è necessario utilizzare AssemblyFileVersion con un caramello illegale ('*').

opportunamente finisce con "Se continui a credere che questo sia un bug" ....

Hai riprodotto l'errore, ed è stato uno scenario realistico?