Autor Beitrag
Christoph1972
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Fr 10.09.10 20:18 
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?

_________________
Gruß
Christoph
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Fr 10.09.10 20:58 
user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
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"

_________________
Gruß
Christoph
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: 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.

_________________
Gruß
Christoph
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Fr 10.09.10 22:17 
user profile iconChristoph1972 hat folgendes geschrieben Zum zitierten Posting springen:
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?

user profile iconChristoph1972 hat folgendes geschrieben Zum zitierten Posting springen:
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.

user profile iconChristoph1972 hat folgendes geschrieben Zum zitierten Posting springen:
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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Fr 10.09.10 22:48 
So, ich habe was rausgefunden. Wenn ich das Control von Hand der ControlCollection zufüge funktioniert es:

ausblenden C#-Quelltext
1:
2:
3:
OracleAccessControl t = new OracleAccessControl();
this.Controls.Add(t);
t.PointToClient(new Point(2020));

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!

_________________
Gruß
Christoph
Christoph1972 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: 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...

_________________
Gruß
Christoph