Christoph1972 - Fr 10.09.10 20:18
Titel: Wie Usercontrol(DLL) intern serialisieren?

---

Hallo Leute,

ich schraube mir gerade ein DAL zusammen, als UserControl(DLL). Nun möchte ich die Zugangsdaten intern serialisieren. Der User, in diesem Fall der Programmierer, soll sich also nicht um die Serial/Deserialisierung kümmern müssen. Nun stehe ich vor dem Problem, das ich nicht weis wohin ich die Datei speichern kann, da ja "Application.UserDataPath" in der DLL einen Pfad vom FrameWork zurückgibt und es somit ein Problem bei der Deserialisierung besteht. "Ich bräuchte irgendetwas wie this.Parent.Application.UserAppDataPath".

Hat hier jemand eine Idee, wie man das lösen könnte?

Ralf Jansen - Fr 10.09.10 20:31

---

Das Problem das du das siehst existiert nicht. Application (darum der Name ;)) bezieht sich immer auf die gesamte Application. Egal wo du in deiner Instanz Applikation darauf zugreifst erhältst du die gleiche Info. Wenn du in deine Dll auf UserAppDataPath zugreifst erhältst du also immer die Info relativ zur startenden Assembly egal in welcher Assembly sich der Code befindet der auf Application zugreift.

Christoph1972 - Fr 10.09.10 20:58

---

Ralf Jansen hat folgendes geschrieben :

Wenn du in deine Dll auf UserAppDataPath zugreifst erhältst du also immer die Info relativ zur startenden Assembly egal in welcher Assembly sich der Code befindet der auf Application zugreift.

Das kann nicht sein, der Debugger zeigt mir einen anderen Pfad. Was könnte denn Grund für den "falschen" Pfad sein?

Das Verzeichnis ist ein verstekter Ordner:
Application.UserAppDataPath = "C:\\Dokumente und Einstellungen\\User\\Anwendungsdaten\\Microsoft Corporation\\Microsoft® .NET Framework\\2.0.50727.42"

Kha - Fr 10.09.10 21:34

---

Irgendwas stimmt da hinten und vorne nicht :) . Reflector zeigt schnell, dass die Informationen aus Assembly.GetEntryAssembly ausgelesen werden - das sollte doch eigentlich passen. Ansonsten: Warum nicht ein eigenes Verzeichnis in AppData anlegen?

PS: Wie man einen ganzen DAL in ein UserControl bekommt, musst du mir noch einmal erklären.

Christoph1972 - Fr 10.09.10 22:00

---

Zitat:

Irgendwas stimmt da hinten und vorne nicht :) . Reflector zeigt schnell, dass die Informationen aus Assembly.GetEntryAssembly ausgelesen werden - das sollte doch eigentlich passen.

Hm, aber was könnte die Ursache sein? Ich habe das Problem hier und bei der Arbeit. Ok, ich das Projekt kopiert um Zuhause weiter zu arbeiten, da werde ich das Problem wohl mit kopiert haben.

Zitat:

Ansonsten: Warum nicht ein eigenes Verzeichnis in AppData anlegen?

Ich denke weil das nicht UAC-Konform ist, oder? Ausserdem hat der Pfad auch nicht hin, hier lautet er:
Application.StartupPath = "C:\\Programme\\Microsoft Visual Studio 8\\Common7\\IDE"

Zitat:

PS: Wie man einen ganzen DAL in ein UserControl bekommt, musst du mir noch einmal erklären.

Ne, da kommmen nur Dinge rein die sich kaum verändern, Zugangsdaten(serialisiert), ConnectionStringBuilder, Methoden zum Prüfen ob eine Verbindung mit den eingegeben Daten erstellt werden kann. Funktionen, die z,B. eine List<>, unter Angabe Table & Column, zurückgeben. Eigentlich ein Tool das jeder verwenden kann, der mit Oracle oder SQL-Server arbeitet. Abfragen/Updates usw werden getrennt gehalten.

Kha - Fr 10.09.10 22:17

---

Christoph1972 hat folgendes geschrieben :

Hm, aber was könnte die Ursache sein? Ich habe das Problem hier und bei der Arbeit. Ok, ich das Projekt kopiert um Zuhause weiter zu arbeiten, da werde ich das Problem wohl mit kopiert haben.

GetEntryAssembly liefert die richtige zurück? Wie ist der Firmenname festgelegt, per Attribut? Kein ClickOnce-Projekt, oder?

Christoph1972 hat folgendes geschrieben :

Zitat: Ansonsten: Warum nicht ein eigenes Verzeichnis in AppData anlegen? Ich denke weil das nicht UAC-Konform ist, oder? Ausserdem hat der Pfad auch nicht hin

Ich rede von SpecialFolder.ApplicationData, wo du ursprünglich ja sowieso hin wolltest. Ich sehe aber gerade erst, dass der Aufrufer der Assembly gar nicht bekannt ist, also müsste der gewünschte Ordnername von ihm übergeben werden.

Christoph1972 hat folgendes geschrieben :

Zitat: PS: Wie man einen ganzen DAL in ein UserControl bekommt, musst du mir noch einmal erklären. Ne, da kommmen nur Dinge rein die sich kaum verändern, Zugangsdaten(serialisiert), ConnectionStringBuilder, Methoden zum Prüfen ob eine Verbindung mit den eingegeben Daten erstellt werden kann. Funktionen, die z,B. eine List<>, unter Angabe Table & Column, zurückgeben.

Aber... in einem visuellen UC :eyecrazy: ?

Ralf Jansen - Fr 10.09.10 22:21

---

Was steht den in Application.ExecutablePath für eine Anwendung die angeblich läuft? vshost.exe oder noch was anderes?

Edit: Da hier grad nochmal das Wort UserControl viel eine Nachfrage nur zur Sicherheit. Du hast das Problem beim Debuggen einer Anwendung (Winforms anwendung) und nicht etwa beim designen in Visual Studio deines Usercontrols (also innerhalb deines eventuell erstellten Designercodes des Usercontrols)?

Christoph1972 - Fr 10.09.10 22:48

---

So, ich habe was rausgefunden. Wenn ich das Control von Hand der ControlCollection zufüge funktioniert es:


Wenn ich es mit dem Designer mache klappt es nicht. Morgen werde ich mal meine Toolbox zurücksetzen, hier besteht wohl ein Verweis auf ein älteres Versuchsprojekt.


Vielen Dank fürs erste!!!! Werde mich noch mal melden!

Christoph1972 - Sa 11.09.10 10:10

---

Guten Morgen!

So, wenn ich das Control händisch zufüge funktioniert alles, auch die interne Serialisierung. Wenn ich das Control aus der ToolBox aufziehe gibt es jetzt gleich eine Fehlermeldung:

Die Assembly "EinAltesProjektWasEsNichtMehrGibt", Version=1.0…., PublicKeyToken=null kann nicht gefunden werden.

Ich habe die ToolBox zurückgesetzt und habe dann über Elemente auswählen die brandneue DLL ausgewählt. Der Fehler besteht nach wie vor. Da muss doch in der ToolBox nach wie vor ein Verweis auf die alte Komponente bestehen. Wo kann ich diesen den wohl finden?


Die Serialisierung funktioniert nun. das neue Problem möchte ich in einem extra Thread besprechen...