Sitzung kann für benannten Benutzer nicht erstellt werden?

[Arne Drews]

Moin,

Wir haben ein Umlagerungstool entwickelt, dass auf .NET basiert.
Wenn ich dieses Tool teste, läuft alles, wie es soll, beim Kollegen, der eigentlich buchen soll aber nicht?!

Es kommt immer eine Exception beim Versuch eine Sage Sitzung aufzubauen, der Benutzer ist ein benannter Benutzer der WaWi und kann darin auch problemlos Lagerbuchungen durchführen.

Im Tool kommt nun an dem Punkt, wo die Sitzung aufgebaut wird:

ErpSession = Sagede.OfficeLine.Engine.ApplicationEngine.CreateSession("OLReweAbf", ApplicationToken.Abf, null, new NamePasswordCredential());

kommt beim Benutzer immer diese Exception:

Der Typeninitialisierer für "Sagede.OfficeLine.Shared.Logger" hat eine Ausnahme verursacht.
System.TypeInitializationException: Der Typeninitialisierer für "Sagede.OfficeLine.Shared.Logger" hat eine Ausnahme verursacht.
---> System.TypeInitializationException: Der Typeninitialisierer für "Sagede.Core.Logging.LogManager" hat eine Ausnahme verursacht.
---> System.IO.FileNotFoundException: Die Datei oder Assembly "Sagede.Shared.Base, Version=9.0.0.0, Culture=neutral, PublicKeyToken=4ad8971889b881a9" oder eine Abhängigkeit davon wurde nicht gefunden.
Das System kann die angegebene Datei nicht finden.
bei Sagede.Core.Logging.LogManager.GetTraceHeaderFromEnvironment()
bei Sagede.Core.Logging.LogManager.InitEnvironment()
bei Sagede.Core.Logging.LogManager..cctor()
--- Ende der internen Ausnahmestapelüberwachung ---
bei Sagede.Core.Logging.LogManager.GetLogger(String area, String subArea)
bei Sagede.OfficeLine.Shared.Logger..cctor()
--- Ende der internen Ausnahmestapelüberwachung ---
bei Sagede.OfficeLine.Shared.Logger.LogVerbose(String message, Object[] args)
bei Sagede.Settings.OfficeLine.ConfigurationAccess..ctor(String internalAppName, String internalVersion)
bei Sagede.Settings.OfficeLine.ConfigurationService.get_ConfigurationAccessFactory()
bei Sagede.Settings.OfficeLine.ConfigurationService.get_CommonSettings()
bei Sagede.MultiUser.OfficeLine.MultiUserSession.ValidateServerConnection(String minimumVersion)
bei Sagede.OfficeLine.Engine.Session..ctor(ApplicationEngineInstance applicationEngine, ApplicationToken applicationToken, IClientCallback clientCallback, SessionBehavior sessionBehavior, String linkedTablesList)
bei Sagede.OfficeLine.Engine.SessionManager.CreateSession(String dataSourceNameMain, ApplicationToken applicationToken, IClientCallback clientCallback, NamePasswordCredential credential, SessionBehavior sessionBehavior, String linkedTablesList, String serviceKey)
bei Sagede.OfficeLine.Engine.ApplicationEngine.CreateSession(String dataSourceNameMain, ApplicationToken applicationToken, IClientCallback clientCallback, NamePasswordCredential credential)
bei Voss.GUI.Umlagerung.SageSlx.ErpTransferController.CreateSession(Int16 client)

Problem ist klar, es fehlt die Assembly Sagede.Shared.Base wird nicht gefunden.
Diese habe ich zugefügt und bekomme den nächsten Fehler, dass die Sage.Shared.Core.Diagnostics.dll fehlt.

Meine Fragen: Wo finde ich die nun wieder?
Aber vor allem: Warum fehlen ihm diese DLLs überhaupt. Wir haben andere .NET Applikationen im Einsatz, in denen ich eine Lagerbuchung vornehme, aber diese DLLs auch nicht eingebunden habe. Das läuft trotzdem einwandfrei.

Die Tools werden alle auf die gleiche Weise gestartet. Mir erschließt sich nicht, warum das in diesem Projekt auf einmal relevant ist.

Freue mich über Hinweise und Tipps
Gruß Arne

 

[web2perform]

Hallo Arne,

der Beitrag ist schon älter, deshalb nehme ich an, dass du das Problem lösen konntest?

Trotzdem möchte ich deine Fragen beantworten, damit andere mit den gleichen Fragen ebenfalls eine Antwort erhalten. Sollte ich etwas vergessen oder übersehen haben, ergänzt/korrigiert mich gerne.

Diese habe ich zugefügt und bekomme den nächsten Fehler, dass die Sage.Shared.Core.Diagnostics.dll fehlt.

Meine Fragen: Wo finde ich die nun wieder?

Entweder im Shared-Ordner oder, wie im Falle der Sagede.Shared.Core.Diagnostics.dll, im GAC (C:\Windows\Microsoft.NET\assembly\GAC32).

Warum fehlen ihm diese DLLs überhaupt. Wir haben andere .NET Applikationen im Einsatz, in denen ich eine Lagerbuchung vornehme, aber diese DLLs auch nicht eingebunden habe. Das läuft trotzdem einwandfrei.

Die Dateien werden für die Anmeldung am Application Server gebraucht.
Der Fehler deutet darauf hin, dass die fehlenden DLLs nicht im Global Assembly Cache (GAC) registriert sind. Demnach fehlt auf dem PC wahrscheinlich der Sage-Client?

Um den Fehlern zu entgehen sehe ich drei Möglichkeiten, zwei Good Practices und eine Bad Practice.

Good Practice 1 (ohne Sage-Installation auf dem Client): Kommunikation zwischen Client und Application Server per API (z. B. SData, SOAP, REST). Dazu wird m. W. nur die Sagede.Shared.Core.dll benötigt.

Good Practice 2 (wenn Sage auf dem Client installiert ist): Direkte Nutzung der Sage-Bibliotheken, aber Ablage der EXE-Datei im Shared-Ordner. So kann garantiert werden, dass die Assemblies bei einem Liveupdate aktualisiert werden.

Bad Practice: Direkte Nutzung der Sage-Bibliotheken, aber Ablage der EXE-Datei in einem anderen als dem Shared-Ordner oder sogar auf einem PC ohne Sage-Client. Somit müssen alle DLLs mit kopiert werden, was die Wartung bei Liveupdates erschwert.

Beste Grüße
Marcel von web2perform

 

[Arne Drews]

Hi Marcel,

Trotzdem möchte ich deine Fragen beantworten, damit andere mit den gleichen Fragen ebenfalls eine Antwort erhalten. Sollte ich etwas vergessen oder übersehen haben, ergänzt/korrigiert mich gerne.

Immer gerne gesehen! Je mehr Infos, desto hilfreicher für alle!

Entweder im Shared-Ordner oder, wie im Falle der Sagede.Shared.Core.Diagnostics.dll, im GAC (C:\Windows\Microsoft.NET\assembly\GAC32).

Das hatte ich tatsächlich bereits gefunden.

Die Dateien werden für die Anmeldung am Application Server gebraucht.
Der Fehler deutet darauf hin, dass die fehlenden DLLs nicht im Global Assembly Cache (GAC) registriert sind. Demnach fehlt auf dem PC wahrscheinlich der Sage-Client?

Dass die benötigt werden war soweit schon klar, aber es war mir unverständlich, warum es das einzige Projekt war, bei dem die nicht im GAC auffindbar waren. Unsere .NET Projekte werden ausschließlich auf unseren Terminal-Servern ausgeführt ( Verteilung über Parallels Client ), wo der Sage-Client auch installiert ist. Die Umgebung für die Anwendung ist also absolut identisch mit allen anderen Anwendungen.

Good Practice 1 (ohne Sage-Installation auf dem Client): Kommunikation zwischen Client und Application Server per API (z. B. SData, SOAP, REST). Dazu wird m. W. nur die Sagede.Shared.Core.dll benötigt.

Mit der API habe ich bisher noch nichts gemacht, wäre aber generell mal ein zukünftiger Ansatz, danke.

Good Practice 2 (wenn Sage auf dem Client installiert ist): Direkte Nutzung der Sage-Bibliotheken, aber Ablage der EXE-Datei im Shared-Ordner. So kann garantiert werden, dass die Assemblies bei einem Liveupdate aktualisiert werden.

Es mag an meinem inneren Monk liegen, aber Custom-Executables lege ich nicht im Shared-Verzeichnis ab.
Der Vorteil, den Du angesprochen hast ist nicht von der Hand zu weisen, aber es fühlt sich für mich persönlich nicht good an.
Zudem hat es bei mir noch nie funktioniert, einfach die aktualisierten DLLs zu hinterlegen, ich musste nach einem Live-Update fast immer die Projekte gegen die aktualisierten DLLs einmal neu kompilieren. Das würde sich aus meiner Sicht auch auf diese Art nicht verhindern lassen?

Bad Practice: Direkte Nutzung der Sage-Bibliotheken, aber Ablage der EXE-Datei in einem anderen als dem Shared-Ordner oder sogar auf einem PC ohne Sage-Client. Somit müssen alle DLLs mit kopiert werden, was die Wartung bei Liveupdates erschwert.

You got me, I'm a baddy
Ich habe ein Verzeichnis für unsere eigenen Projekte und gehe den bad way, die DLLs mitzuführen.
Wie Du schon schreibst, nicht der beste Weg, aber von der Wartung her ist das für mich nicht großartig umständlich.

Danke für Deine Ausführungen, die in jedem Fall hilfreich sind!