in unserer Anwendung kann der Anwender Berichte öffnen und bearbeiten. Derzeit nutzen wir noch die Version 22. Zum Testen, ob die Migration klappt, haben wir eine separate Version verteilt, welche mit Version 24 arbeitet. Für die 24er Version haben wir die aktuelle Software verwendet und nur die Pakete und Verweise für List & Label 24 angepasst (listlabel24.dll, cxll24.dll etc…). Ansonsten wurden keine Änderungen durchgeführt, um eventuelle Seiteneffekte durch andere Änderungen im Code auszuschließen.
Die Berichte wurden alle mit List & Label 22 erstellt und gespeichert. Beim bearbeiten der Berichte (mit der Anwendung die LL24 verwendet) erscheint eine Warnmeldung, dass eine neue Version verwendet wird. Das ist korrekt.
Wenn der Anwender (welcher das Programm mit LL22 und LL24 lokal verfügbar hat) die Programmversion mit LL22 startet erfolgt dieser Warnhinweis ebenfalls. Über den Prozess-Explorer kann ich nachvollziehen, dass (je nach Version) korrekterweise LL22 oder LL24 geladen werden.
Mit den DLL-Referenzen scheint alles in Ordnung zu sein. Der Designer wurde jedoch irgendwie auf Version 24 aktualisiert. Im Programmcode wird LL.Design(..); für den Aufruf verwendet. Ein Anwender, welcher nur die LL22-Version nutzt, erhält keine Fehler. Die parallele Nutzung (identische Anwendung. Ein Mal mit LL22, anderes Mal mit LL24) scheint Probleme zu bereiten oder intern (registry?) Komponenten umzustellen
Kann es sein, dass List&Label globale Komponenten besitzt, die durch den Start von LL24 aktualisiert wurden? Aus meiner Sicht macht es keinen Sinn, mit der LL22-Anwendung eine Warnung zu erhalten, dass der Bericht aktualisiert wird. Um eventuelle Probleme bei den Berichten vor dem großen Rollout auszuschließen, haben wir extra zwei Programmversionen mit unterschiedlichen LL-Versionen erstellt.
Bei Anwendern, die nur die Anwendung mit List & Label 22 geöffnet haben, tritt dieses Verhalten nicht auf. Es erscheinen keine Warnungen oder Fehlermeldungen. Kann ich dem Designer mitgeben, welche List&Label-Version im Hintergrund geladen werden soll?
Wie gesagt, ist die einzige Änderung der Austausch der DLLs und Referenzen im Projekt vom Visual Studio und das manche Nutzer eine Version mit LL22 und LL24 parallel nutzen. Auch ein Neustart oder beenden der Anwendung (sodass nur eine ausgeführt wird) haben nicht geholfen.
Könnten Sie einmal einen Blick in ein Debug-Log (mit Debwin4 erstellt) werfen oder das ganze mal hier anhängen? Ich würde mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, dass irgendwo in der LL22-Applikation versehentlich noch ein LL24-Verweis steckt. Der Designer wird direkt als Funktion der referenzierten DLL aufgerufen (LlDefineLayout, das macht der Aufruf von Design implizit), da kann eigentlich nur die falsche DLL geladen sein.
Sie können das auch verifizieren, wenn Sie im Designer Strg+Umschalt+F12 drücken, dann sehen Sie die Version.
danke für die schnelle Rückmeldung. Dass die 22er Version einen Verweis auf die 24 hat kann ich ausschließen. Derzeit wird bei uns noch mit der 22er gearbeitet. Mittels GIT habe ich unsere aktuellste freigegebene Version ausgecheckt, um die Migration nach LL24 zu testen und ein paar Kollegen für interne Tests (insbesondere bzgl. der Berichte) eine “Spezialversion” der Software bereitzustellen.
Ich habe die beiden Versionsinformationen aus der LL22-Anwendung und LL24-Anwendung angehängt: LL22.txt (2.9 KB) LL24.txt (3.4 KB)
Die Verweise im Visual-Studio haben wir ebenfalls auf LL24 aktualisiert mit Hilfe des NuGet-Packages:
Auf dem Testrechner haben wir folgende Schritte durchgeführt:
Die LL22-Version (aktuelles Release unserer Software) ist installiert
Die LL24-Version ist eine Zip-Datei mit der EXE und den Bibliotheken (erstellt mittels Visual Studio)
Bericht mit LL22 öffnen -> Keine Meldungen oder Fehler
LL22-Anwendung beenden
LL24-Anwendung starten (das erste Mal)
Bericht mit LL24 öffnen -> Warnung, dass der Bericht nicht in älteren Versionen verwendet werden kann (ist in Ordnung)
LL24-Anwendung beenden
LL22-Anwendung starten (die installierte, aktuelle Freigabeversion)
LL22-Anwendung öffnet einen Bericht -> Warnmeldung, dass die Version des Berichts nicht stimmt
Wir prüfen allerdings noch, ob beim Laden/Speichern der Berichte alles korrekt läuft oder ob es ein PC-Spezifisches Problem ist. Auf einem Computer hatten wir o.g. Verhalten. Bei einem Schnelltest auf einer virtuellen Maschine trat das Verhalten nicht auf.
Eine Möglichkeit wäre natürlich noch, dass der fragliche Bericht noch aus einer Version < 22 stammt, auch dann würde sich dieses Verhalten zeigen .
Sie können dies leicht prüfen, wenn Sie die Datei in einem Editor öffnen - Version 22 hatte die FileVersion 14:
[List description]
[Description]
Text=List & Label Generic List
FileVersion=14
Der Vollständigkeit halber: die Meldung lässt sich auch abschalten, indem man LL.Core.LlSetOption(LlOption.NoFileVersionUpgradeWarning, 1) aufruft. Dennoch sollten Sie natürlich klären, was genau in Ihrer Umgebung schiefläuft.
jbartlau
(combit - Jochen Bartlau)
Split this topic
5
.