(gelöst) Eigene dll einbinden (CC)

Servus zusammen,

wir haben bei uns eine Schnittstelle von NAV zu einem DMS-System. Hierfür wurde eine dll erstellt, damit man mit der DMS-Schnittstelle kommunizieren kann.
Unsere DLL liegt im "Add-ins"-Verzeichnis und wurde von dort aus auch per regasm registriert.

Nun konnte ich die DLL und derer Funktionen in NAV als Automation ansprechen und entsprechend kompilieren und speichern.
Wenn ich nun aber eine Instanz dieser DLL erstellen will erscheint folgende Meldung:

----------------------------------------------------------------------------------------------------------------------------------------------------------
Diese Meldung ist für C/AL-Programmierer:

Für das OLE Control oder den Automation Server
GUID={9D3B7A5D-059F-4344-AA90-BDB7E7FBA3FC} 1.1:{C83BF995-CFE5-4A84-A552-D805CB0F4E08}:[meineDLL.Funktion] konnte keine Instanz erstellt werden.
Prüfen Sie, ob das OLE Control oder der Automation Server korrekt installiert und registriert wurde.
-----------------------------------------------------------------------------------------------------------------------------------------------------------

Ich versuche wie folgt eine Instanz zu erstellen

IF ISCLEAR(Variable) THEN
CREATE(Variable, TRUE, TRUE);


Was muss ich noch machen, damit ich eine Instanz erstellen kann?
Richtig registriert müsste sie ja sein, da ich sie sonst innerhalb NAV nicht ansprechen könnte.

Ich hoffe ihr könnt mir weiter helfen. Ich versuche dies schon seit 3 Tagen zu lösen und habe schon etliche Forumeinträge gelesen, aber meist steht nur, dass man sie registrieren muss etc.

Grüße
Kai

Zuletzt geändert von Kai R. am 24. März 2016 12:50, insgesamt 2-mal geändert.

[Kowa]

Bitte angeben ob CC oder RTC verwendet wird.
CREATE(Variable, TRUE, TRUE)) erstellt die Instanz auf dem Client. Ist das so gewollt? Wenn nicht, diesen Parameter auf FALSE.
https://msdn.microsoft.com/de-de/library/dd355255.aspx

Unsere DLL liegt im "Add-ins"-Verzeichnis […]

Welches "Add-ins" Verzeichnis? Client oder Server?

Zuletzt geändert von Kowa am 22. März 2016 23:43, insgesamt 2-mal geändert.
Grund: Client/Server-Vertauschung korrigiert

Letztes True ist umgekehrt, meint also Client. Add-ins gibts nur im Client Vrrzeichnis unter 2009

Fehlt eventuell eine abhängige DLL?

Ich habe das Create bereits mit beiden boolean-Werten bei beiden Parametern getestet.
Bei allen 4 Möglichkeiten kam die gleiche Fehlermeldung. Kann es aber gerne morgen früh noch einmal probieren.

Die registrierte DLL ruft tatsächlich weitere DLLs auf. Diese sind aber alle vorhanden.
Ich habe die Dateien aus einem bereits bestehenden System heraus genommen und wollte diese einfach einbinden.

Gruß
Kai

Liegen die DLLs auch alle im selben Verzeichnis und sind diese ebenfalls registriert sofern notwendig?

Alle DLLs liegen im selben Unterordner in "Add-ins" von Classic.
Da die weiteren DLLs nur über die eingebundene DLL aufgerufen wird, bin ich mir nicht sicher, ob diese registriert werden müssen?!
Es werden einige DLLs über die Haupt-DLL aufgerufen. Im System woher ich die DLLs genommen habe, schaut es nicht so aus, als würden die weiteren registriert worden.

Edit: Wenn man die DLL in NAV benutzen kann, kann man davon ausgehen, dass sie mit dem richtigen Framework installiert ist?
Habe nämlich auch gelesen, dass sie mit dem gleichen Framework registriert werden müssen, wie sie erstellt wurde.

Gruß
Kai

Letztes True ist umgekehrt, meint also Client.

Danke, Ist oben korrigiert. Die nachfolgende Frage gilt natürlich auch weiterhin .

Letztes True ist umgekehrt, meint also Client.

Danke, Ist oben korrigiert. Die nachfolgende Frage gilt natürlich auch weiterhin .

Die hatte Silver schon beantwortet. Unter 2009 gibt es nur Client.

Gruß
Kai

Hallo,

Deine DLL ist doch "Strong named" oder?
Du haste keine alte Version der DLL rumliegen?
Die DLL stellt auch ein COM- Interface zur Verfügung?
Die Automation wurde mit regsvr32 registriert?

Gruß Fiddi

Hallo,
Deine DLL ist doch "Strong named" oder?
Gruß Fiddi

Woran erkenne ich dies? Da ich es aber aus einem bereits bestehenden System genommen habe, gehe ich davon aus.
Bin in diesem Themengebiet ziemlicher Neuling.

Du haste keine alte Version der DLL rumliegen?

Nein, leider habe ich nur diese Version und eine, die ich einfach mal mit neuestem Framework neu erstellt habe.

Die DLL stellt auch ein COM- Interface zur Verfügung?

Was ist ein COM-Interface und wo müsste man dies dann finden?

Die Automation wurde mit regsvr32 registriert?

Die Automation wurde mit regasm registriert. Versuche ich die DLL mit der regsrv32 aus zu führen, erhalte ich den Fehler:

Das Modul C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic\Add-ins\MEINEDLL.dll wurde geladen, aber der DllRegisterServer-Eingangspunkt wurde nicht gefunden.
Stellen Sie sicher, dass C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic\Add-ins\MEINEDLL.dll eine gültige .DLL- oder .OCX-Datei ist, und wiederholen Sie den Vorgang.

Edit:
Meinen Aufruf "CREATE(Variable, TRUE, TRUE);" habe ich nochmal mit allen 4 Möglichkeiten getestet. Überall der selbe Fehler.


Gruß
Kai

Hallo,

es ist ein Unterschied, ob du mit DotNet oder Automations arbeitest. Für Automations muss deine Assembly ein COM-Interface bereitstellen, wenn es das nicht tut, hast du ein Problem .
"Strong named" heißt, dass deine Assembly signiert sein muss.

Gruß Fiddi

Hallo Fidii,

leider verstehe ich nur Bahnhof :(
Meine DLL wird als Automation eingebunden. Also brauche ich dieses COM-Interface, wovon ich nicht weiß was dies ist bzw. wann und wohin dies erstellt wird.
"Strong named" muss es in diesem Fall ja nicht sein, oder?

Gruß
Kai

Unter 2009 gibt es nur Client.

Ab NAV 2009 können die Automations auch auf dem Server laufen, und erst ab NAV 2009 gibt es diesen Parameter, um das unterscheiden zu können. Mehr dazu hier:
Automation Objects in Microsoft Dynamics NAV 2009

Unter 2009 gibt es nur Client.

Ab NAV 2009 können die Automations auch auf dem Server laufen, und erst NAV 2009 gibt es diesen Parameter, um das unterscheiden zu können. Mehr dazu hier:
Automation Objects in Microsoft Dynamics NAV 2009

Hatte da Silver vertraut.
Dann ist meine Antwort auf die Frage wie folgt:
Die DLL und alle anderen Komponente liegen in einem Unterverzeichnis zu
C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic\Add-ins.
Es wird auch nur der CC benutzt.

Gruß
kai

Hatte da Silver vertraut.
Dann ist meine Antwort auf die Frage wie folgt:
Die DLL und alle anderen Komponente liegen in einem Unterverzeichnis zu
C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic\Add-ins.
Es wird auch nur der CC benutzt.

Gruß
kai

Vertrauen war Ja auch OK, du schriebst Ja schon classic und da gibt's keinen Server

Es kann aber trotzdem eine DLL fehlen, die von dieser oder einer referenzierten DLL genutzt wird. Eine aus dem global assembly Cache (des anderen rechners) z.B.

Es kann aber trotzdem eine DLL fehlen, die von dieser oder einer referenzierten DLL genutzt wird. Eine aus dem global assembly Cache (des anderen rechners) z.B.

kann man dies iwie herausfinden ohne jede Assembly, die auf dem anderen Rechner ist, zu checken?

Gruß
kai

Schau dir mal die Lösungen an, die hier vorgeschlagen werden. Nicht zwingend die erste: How do I determine the dependencies of a .NET application?

Vertrauen war Ja auch OK, du schriebst Ja schon classic und da gibt's keinen Server

Um das vorab zu klären, war ja auch die erste Frage in Rot da, die bislang noch offen war .

Alles Ok. Ich schreibe Ja nur soviel, damit ich endlich mal auf meine 1000 Posts komme :)

Schau dir mal die Lösungen an, die hier vorgeschlagen werden. Nicht zwingend die erste: How do I determine the dependencies of a .NET application?

Ich habe mich mal für den ".NET Dependeny Walker" entschieden.
Öffne ich meine DLL mit diesem Programm werden mir alle Informationen angezeigt.
So wie ich das sehe, kann ich aber keine fehlende Datei finden. Alles sieht gut aus. (Zumindest sehe ich nichts rotes).

Im GAC ist meine DLL nicht vorhanden, habe ich über das Programm herausbekommen, aber die Assembly ist vorhanden.

Versuch war nun auch die DLL nicht über Automation sondern über DotNet anzusprechen. Hierbei erfolgt beim Öffnen der Assembly-Liste folgende Fehler:
--------------------------.
.NET-Interop: Ausnahme 'Die Datei oder Assembly "C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic\Add-ins\MEINEDLL.dll" oder eine Abhängigkeit davon wurde nicht gefunden. Die Assembly wird von einer Laufzeit erstellt, die aktueller als die derzeit geladene Laufzeit ist, und kann nicht geladen werden.'.
---------------------------

Dieser Fehler erscheint für meine Haupt-DLL und jede DLL, die darin irgendwie angesprochen wird.
Was ist mit Laufzeit gemeint?


Ich weiß echt nicht mehr weiter :(

Gruß
Kai

Hallo,

welches DotNet- Framework hast du denn für deine DLL verwendet?

Gruß Fiddi

Hallo,

welches DotNet- Framework hast du den für deine DLL verwendet?

Gruß Fiddi

Das ist die korrekte Frage. Die Meldung wurde leider "sauber" übersetzt und der Begriff Laufzeit lautet eigentlich "Runtime". Die Fehlermeldung deutet also darauf hin, dass die DLL für (wahrscheinlich) .NET 4+ (CLR4) erstellt wurde, aber NAV 2009 nur mit Version bis 3.5 soweit ich weiß klar kommt.

Eventuell fehlt auch einfach nur das .NET Framework in der richtigen Version, schau mal nach ob die installierten Windows Komponenten der zwei Rechner identisch sind (.NET Framework) und ob die Zielversionen der DLL auf Rechner A noch der Zielversion auf Rechner B entspricht (vielleicht auch beim Testen und neukompilieren geändert).

Hallo,

welches DotNet- Framework hast du denn für deine DLL verwendet?

Gruß Fiddi

Laut einem Kollegen wurde die DLL mit DotNet-Framework 4.0.0 erstellt. Damit habe ich es auch registriert.
Jetzt wo ihr sagt, dass NAV2009 nur bis 3.5 geht, sind es definitiv unterschiedliche Versionen. Das könnte das Problem sein.
Das System, aus dem ich die DLL habe, ist NAV 2013. Das wird wohl schon weiter als DotNet-Framework 3.5 sein?!

Das erklärt zumindest warum ich es als DoteNet nicht ansprechen kann, oder kann dies auch die Ursache dafür sein, dass ich bei der Automation keine Instanz erstellen kann?

Gruß
Kai

Das mit 2013 auf dem anderen System wäre natürlich eine zielführende Information gewesen. Ja, genau daran wird es liegen.