Moin,
ich weiß nicht genau, ob es ein Verständnisproblem ist oder ob ich einfach irgendwas komplett falsch mache.
In den Projekteigenschaften eines Projektes (enthält nur Klassen), habe ich in den Settings mehrere Strings hinterlegt. Diese frage ich dann mit "Properties.Settings.Default.SettingsName" ab. Funktioniert einwandfrei, wenn ich das ganze in Visual Studio starte.
Wenn ich jetzt allerdings das ganze im Release Modus baue und auf einem anderen System ausführe, dann findet er diese Settings nicht mehr.
Lösung des ganzen scheint zu sein, dass er die app.config (in der wohl diese Werte gespeichert werden), nur vom anderen Projekt in der Solution nimmt (in der sich die Exe für das ganze befindet). Am Ende hab ich dann eine Config Datei des "Exe-Projekts", aber vom "Dll-Projekt" habe ich nur die DLL.
Was wäre in diesem Fall denn die richtige, elegante Lösung?
ich weiß nicht genau, ob es ein Verständnisproblem ist oder ob ich einfach irgendwas komplett falsch mache.
In den Projekteigenschaften eines Projektes (enthält nur Klassen), habe ich in den Settings mehrere Strings hinterlegt. Diese frage ich dann mit "Properties.Settings.Default.SettingsName" ab. Funktioniert einwandfrei, wenn ich das ganze in Visual Studio starte.
Wenn ich jetzt allerdings das ganze im Release Modus baue und auf einem anderen System ausführe, dann findet er diese Settings nicht mehr.
Lösung des ganzen scheint zu sein, dass er die app.config (in der wohl diese Werte gespeichert werden), nur vom anderen Projekt in der Solution nimmt (in der sich die Exe für das ganze befindet). Am Ende hab ich dann eine Config Datei des "Exe-Projekts", aber vom "Dll-Projekt" habe ich nur die DLL.
Was wäre in diesem Fall denn die richtige, elegante Lösung?
|
375 ● 1 ● 5 |
2 Antworten
Ich habe zwar keine Lösung für das Problem an sich, aber generell würde ich spezielle Settings im aufrufenden Programm speicher und beim Aufruf der Dll-Klasse mitgeben und nicht in den aufzurufenden Dll's speichern.
Damit hättest du u.a. eine höhere Wiederverwendbarkeit deiner Dll's sichergestellt, da jedes Programm mit unterschiedlichen Settings diese nutzen kann.
Damit hättest du u.a. eine höhere Wiederverwendbarkeit deiner Dll's sichergestellt, da jedes Programm mit unterschiedlichen Settings diese nutzen kann.
|
43 ● 1 ● 3 |
Inzwischen hab ich was von MS gefunden:
http://social.msdn.microsoft.com/forums/en-US/vblanguage/thread/890448df-4545-415c-8628-af54e7c33603/
Das gehört also einfach so.
@13thAngel:
Ist halt die Frage ob man mehr Komfort will oder ob man die Wiederverwendbarkeit steigern möchte. Hier sollte es einfach Richtung Komfort gehen, damit andere einfach nur noch die Funktion aufrufen müssen und alles andere passiert automatisch.
Naja, dann hau ichs entweder in die Ressourcen Datei oder mach mir eine Public Constanten Klasse. :)
http://social.msdn.microsoft.com/forums/en-US/vblanguage/thread/890448df-4545-415c-8628-af54e7c33603/
Das gehört also einfach so.
@13thAngel:
Ist halt die Frage ob man mehr Komfort will oder ob man die Wiederverwendbarkeit steigern möchte. Hier sollte es einfach Richtung Komfort gehen, damit andere einfach nur noch die Funktion aufrufen müssen und alles andere passiert automatisch.
Naja, dann hau ichs entweder in die Ressourcen Datei oder mach mir eine Public Constanten Klasse. :)
|
|
375 ● 1 ● 5 |
