Definieren Sie einen benutzerdefinierten Pfad, in dem die Datei user.config gespeichert werden soll?

Question

Wenn ich meine kompilierte Anwendung zum Beispiel myapp.exe-app.exe dann umbenennen, wenn ich die umbenannte ausführbare Datei einen neuen Benutzereinstellungen Ordner erzeugt in diesem Pfad laufen:

C:\Users\{User}\AppData\Local\{CompanyName}\{ExecutableName}_Url_{SystemGUID or something strange} 

Also alles, was ich verlieren die gespeicherten Einstellungen.

Dann, wie ich kann dieses Problem in einer VBNETWinForms meine eigenen Position zu definieren löse die user.config Datei zu speichern, oder jede andere Lösung, um die Infrastruktur application? (Nicht die Einstellungen auf der Registry oder andere Dinge zu speichern)

PS: Ich habe dieses SO Beitrag gelesen, die etwas andere Frage ist aber sowieso habe ich nicht die vermeintliche Lösung Can I control the location of .NET user settings to avoid losing settings on application upgrade?

Answer 1

Mehr Infos und ein Leckerbissen aus der Verbindung, die Ihre Frage beantwortet:

Das "systemGUID oder etwas" Sie verweisen eigentlich ein Hash-Wert von 2 Dingen ist (Referenz MSDN My.Settings):

<eid> is the URL, StrongName, or Path, based on the evidence available to hash. 
<hash> is a SHA1 hash of evidence gathered from the CurrentDomain, 
    in the following order of preference: 
    - StrongName 
    - URL If neither of these is available, use the .exe path. 

Without a StrongName, Ihr Standort variiert je nach Pfad, was das Problem ist, das Sie beschreiben. Da BEIDE und Hash StrongName für die Hashs verwenden, sollte der vollständige Pfad gleich bleiben, auch wenn sie ihn woanders hin verschieben oder eine neue Version installieren. Wenn Sie einen StrongName verwenden, stammen die Anmeldeinformationen von der App und die Hashwerte ändern sich nicht, und die Methode des letzten Ausweges (der Exe-Pfad) wird nie verwendet. Was beantwortet Ihre grundlegende Frage: Verwenden Sie einen starken Namen und der Pfad wird sich nicht ändern.

Neue Releases/Versionen erstellen einen Unterordnerbaum unter diesem Ordner für jede Version für Einstellungen. Die im Link erwähnte Methode für Settings (scheinbar) erleichtert das Importieren von Einstellungen aus der/einer früheren Version. Eine Änderung in dem EXE-Name wird jedoch das AppDomain.FriendlyName (drittes Element) ändern.

Isolierte Speicher ist eine andere Option, und es ist nicht so schwer wie es aussieht, aber hat ein ähnliches Verhalten. Mit Iso geben Sie keinen Ordner an, da dieser nur an einem unbekannten Ort wie Users\<User>\Isolated Storage\zhxytg\dhfyres\ erstellt wird. Der Speicherort kann für alle Versionen der App unverändert bleiben, auch wenn Sie ihn umbenennen, wenn Sie ClickOnce verwenden (dies ist also eine andere praktikable Lösung).

Ich denke, Sie müssen ClickOnce (StrongName als Ersatz nicht in MSDN kommen), um Anwendungsebene Beweise zu erhalten. Als Nebeneffekt, mit ISO, kann ein Benutzer ohne Administratorrechte unter ProgramData\AllUsers (wie es für eine Lizenz oder gemeinsame Einstellungen für eine App-Suite der Fall sein kann) mindestens mit W7 lesen/schreiben. Der Hash der App erlaubt es, in diesen Pfad zu schreiben, so dass er einige Dinge tun kann, die wir normalerweise nicht tun können.

Wenn Sie ClickOnce nicht verwenden, können Sie immer noch einen stabilen Ordner per Installation erhalten und lesen/schreiben zu AllUsers. Eine neue Installation (in einen anderen Ordner) führt zu einem anderen Hash- und Dateispeicherort; Gleiches mit dem Ändern des Dateinamens. Selbst wenn es Ihnen gelungen ist, den alten Speicherort irgendwo zu speichern, würde eine neue Installation wahrscheinlich keine Rechte für die alte Datei haben (nicht versucht).

ISO entfernt verschiedene durch EXEName, aber es verwendet nicht My.Settings. Stattdessen verwenden Sie IsolatedFileStreams erstellt von IsolatedStorageFile Objekte. Und Sie müssten die Werte und Namen der verschiedenen Einstellungen organisieren und verwalten. Die Art des verwendeten isolierten Speichers (App/Benutzer) hängt von den verfügbaren Anmeldeinformationen ab.

Isolierter Speicher hat seinen Platz, scheint aber für Einstellungen übertrieben zu sein.

---

Sie erwähnten, dass Sie in der Regel nur MySettings für triviale Apps verwenden. Daher scheint ein StrongName, um den Pfad für die Einstellungen zu stabilisieren, übertrieben zu sein. ISO ist sehr interessant, aber es gibt etwas viel einfacheres. Diese dritte Option fällt in die or other things, die Sie nicht wollten, aber ist sehr flexibel.

Erstellen Sie Ihre eigenen Einstellungen Klasse um Serialisierung. Für einfache Einstellungen sind diese wahrscheinlich nicht viel mehr als eine Gruppe von Name-Wert-Paaren {LastPath = "....."; FormLeft = x; FormTop = y ...}. Speichern Sie diese in einem Dictionary(Of String, String) oder Dictionary(Of enumSettings, String) und nur serialisiert (speichern), um den gesamten Behälter:

Dim bf As New BinaryFormatter 
Using fs As New FileStream(myFile, FileMode.OpenOrCreate) 
    bf.Serialize(fs, _UserOpts) 
End Using 

die Werte zurück zu bekommen ist genauso einfach. Für komplexere Projekte, in denen viele Datentypen wie Integer, Date, Array, ArrayList, Liste (von T) usw. gespeichert werden, erstellen Sie eine UserOptions-Klasse für sie und serialisieren Sie stattdessen.

Beachten Sie, dass Sie einen Filestream an die Serialisierer übergeben, damit Sie die volle Kontrolle über den Namen und den Speicherort haben, z. B. C:\Users\<username>\AppData\Local\<Company>\<Product>\Settings.bin Der Speicherort ändert sich nicht nach Version, Kultur, Assembly usw. Er bleibt dort, wo Sie ihn platzieren.

Dies geht aus, wenn Sie versuchen, Typen wie Punkt, Größe und Schriftart zu sortieren, weil Objekte nicht direkt serialisiert werden können. Insbesondere mit ProtoBuff gibt es mehrere Optionen, um diese in etwas Serializable on the fly oder vorher zu konvertieren.

Answer 2

verstand ich Sie vermuten, könnte auch Ihre Konfigurationsdatei von einem bestimmten Ort mit ConfigurationManager.OpenExeConfiguration Methode öffnen.

Ich hoffe, ich half!