exe und dll im Setup-Projekt

Ich benutze das Multi-Language-Add-In seit einigen Tagen. Prinzipiell eine sehr gute Sache, die einiges vereinfacht. Auch die Fenster und das Auswählen von zu übersetzenden Texten ist sehr komfortabel.
Es tauchen aber allmählich einige Fragen auf:confused

Ich habe eine normale Anwendung Test.exe, in der MlString.cs etc. integriert sind und alles funktioniert. Dann habe ich eine Klassenbibliothek Test.dll; in dieser dll ist ebenfalls MlString.cs integriert, in dem ich allerdings den "namespace" angepasst habe, so dass in der gesamten dll das "using MultiLang" entfällt.
Das Einbinden der dll, d.h. ein Aufruf aus der Test.exe funktioniert ebenfalls. Je nach Spracheinstellung erscheint das Formular der dll in der gewünschten Sprache.
arrowProblem beim Erstellen eines Setup-Projektes für diese exe unter Einbindung der dll. Die Resourcen der dll werden nicht gefunden, d.h. das Formular aus der dll wird in der Originalsprache angezeigt. Welche Dateien muss ich wohin tun ?

Dabei fiel mir noch folgendes auf:

In der Datei MlString.cs stehen statische Funktionen zur Verfügung. Es fällt auf, dass
bei jedem Aufruf von ml.ml_string(ID,Text) in der Funktion static ml() ein neuer
ResourceManager initiiert wird (new ResourceManager()).
In meiner Anwendung tauchen sehr viele Übersetzungen auf, so dass das einmalige Erzeugen
des ResourceManagers sicherlich gut wäre.
Oder wird diese Funktion, so wie sie hier ist, noch woanders benutzt ?

Ich hoffe auf Antwort.
Viele Grüße,
Katja

Germany

Hallo Katja,

zuerst zum Namespace MultiLang. Das Add-In fügt die Zeile using MultiLang; automatisch ein, d.h. normalerweise musst du dich gar nicht darum kümmern. Auch wenn du den Namespace in MlString.cs änderst oder enfernst, wird das Add-In weiterhin die Using-Anweisung einfügen, was zugegeben nicht sehr schlau ist.

Eigentlich war ich schon immer im Zweifel, was die beste Vorgehensweise mit dem Namespace ist. Ich sehe folgende Wege:

  • gar kein Namespace in MlString.cs zu definieren
  • den Namespace des Projektes zu ermitteln, und in MlString.cs automatisch einzufügen
  • den Namespace MultiLang zu definieren, und Using-Anweisungen einzufügen

Ich sehe das persönlich neutral, habe aber gedacht, dass der letzte Weg (bei C# Programmieren) am besten ankommen würde.

Bezüglich des Setup-Projekts, muss die Vorgehensweise für die Anwendung Test.exe sowie die Klassenbibliothek Test.dll im Grunde genommen gleich sein. In beiden Fällen erzeugt Visual Studio Unterverzeichnisse in bin/Release (oder auch bin/Debug) für die einzelne Sprachen, z.B. en oder de, und speichert die entsprechende Resourcen-dlls in diese Verzeichnisse. Diese Resourcen-dlls müssen auf das Zielsystem kopiert werden, wo sie in gleich benannte Unterverzeichnisse gespeichert werden müssen.

Entscheidend ist, dass die Resourcen-dlls in Unterverzeichnisse von dem Verzeichnis stehen, wo die ausführbare Datei, z.B. Test.exe oder Test.dll, steht. Wenn mehrere ausführbare Dateien in einem bin Verzeichnis installert werden, dann kommen all deutsche Resourcen-dlls in das Verzeichnis bin\de, usw. (Bei Test.exe und Test.dll würde es freilich einen Namenskonflikt geben.)

Zum Funktion static ml() liegt entweder bei dir oder bei mir ein Irrtum vor. Ich würde behaupten, dass diese Funktion doch nur einmal aufgerufen wird. Kannst du ein Breakpoint setzen und überprüfen wie oft er erreicht wird?

Viele Grüße
Phil


Hallo Phil,

Vielen Dank für die schnelle Antwort. Ich musste leider erst klar stellen, ob das MultiLang-Add-In auch für unsere Projekte im SourceGear Vault funktioniert. Da es das tut, konnte ich mich um das static ml() kümmern. Dabei muss ich zugeben, dass bei MIR der Irrtum vorliegt !

Für den Namespace wähle ich eigenhändig den Namespace des Projektes, denke ich, um das gleichzeitige Benutzen von mehreren dlls übersichtlicher zu machen.

Die Setup-Geschichte muss ich mir nochmal näher angucken. Ich habe das schon mal (ohne MultiLang) so gemacht, wie du geschrieben hast, aber warum es jetzt nicht geklappt hat, finde ich noch heraus.

Ich danke für die Mühe.

Viele Grüße,
Katja