[Gelöst] Schnittstelle DotNet / Automation Server

[Lboettcher]

Hallo,

Ich hab vor 3 Tagen damit begonnen meine Schnittstelle, mit einem Externen Webservice, nach NAV 2013 zu porten.

Mit den NAV Objekten hatte ich kaum Probleme, bis auf dass in 2009 meine C# Schnittstelle mit Automation eingebunden wurde und da es in NAV 2013 Serverseitig nicht mehr funktioniert.

Code:

CREATE(Automation,TRUE,FALSE)

Das Funktioniert in NAV 2013 nicht mehr.
Gut also führe ich die Automation auf der Clientseite aus.

Problem jetzt, er lädt mit file.OPEN(test.xml) eine XML in einen Stream da aber die Automation auf der Clientseite sind kann er diese nicht an die Automation übergeben.

Die Lösung: DotNet
DotNet kann auf dem Server ausgeführt werden jetzt muss ich jedoch meine Schnittstelle anpassen in C#
bekommen nämlich diesen Fehler:

Code:

Microsoft Dynamics NAV
---------------------------

Diese Meldung richtet sich an C/AL-Programmierer: Eine .NET-Variable wurde nicht instanziiert. Es wird versucht, 'asp.Test.RequestFileNameAddon' in 'CodeUnit Test Interface Management' aufzurufen: requestHitList
---------------------------
OK
---------------------------

meine Schnittstelle ist eine DLL diese enthält 1 Stamm Klasse, 20 Unterklassen (mit jeh 20-40 Methoden) und 20 Interface von den Unterklassen
bei der alten Version mit den Automation konnte ich durch dass registrieren der DLL immer auf die 20 Interfaces zu greifen die jeweils die Klassen enthalten wo dann wiederum die Methoden drin sind. Die Stamm Klasse enthält Methoden die von alle Klassen gebraucht werden.

wie wird eigentlich die Instanziierung vorgenommen, hat jemand eine Blog Eintrag oder irgendetwas wie man eine Schnittstelle für DotNet Einbindung in NAV erstellen kann? Was muss ich in C# machen damit es Instanziiert wird?

ich hoffe man versteht was mein Problem ist.

Mit freundlichen Grüßen
Leo

Zuletzt geändert von Lboettcher am 23. Oktober 2012 14:26, insgesamt 2-mal geändert.

Hat denn vielleicht jemand ein Tutorial für eine DotNet DLL die man selber herstellt die auch in NAV 2013 funktioniert?

Hallo,

es ist eigentlich eher ein Problem eine Automation zu erstellen. Visual Studio erstellt eigentlich standardmäßig Dotnet. Du musst zusätzlichen Aufwand treiben, wenn du eine Automation haben willst. Das Problem ist eigentlich nur die Dotnet- DLL richtig zu registrieren. Danach kannst du die gleiche DLL auch als DotNet in NAV benutzen.
Außerdem solltest du noch den Prozessortyp prüfen, für den du die DLL erstellt hast, hier könnte es auch Probleme geben.

Gruß, Fiddi

Hi, Fiddi

ich bin mit Leo an diesem Problem.
Wir können die automation (extra als X86 compiliert) auf allen Rechnern auch als solche verwenden. Wir wollen aktuell aber durch die neue Architektur auf 2013 auf den Datentypen DotNet umsteigen. Hier finden wir allerdings keine Quelle wie man eine eigene DLL Schreibt speziell wie man diese in NAV (C/AL) Instanziiert. Kennt das jemand?
Ausserdem (evtl weiss das einer aus dem Stehgreif) kann NAV in diesem Fall mit NULL (initialwert von einigen Variablen in unserer Anwendung) umgehen? diese werden in den meisten Fällen sogar nur intern in der DLL verwendet. Aber NAV ist halt manchmal eine kleine Diva ;)

Nach dem ich mal alle Variablen nicht als Null deklariert habe bekomm ich diese Meldung:

Code:

Microsoft Dynamics NAV
---------------------------

Diese Meldung richtet sich an C/AL-Programmierer: Es konnte keine Instanz des folgenden .NET Framework-Objekts erstellt werden: Assembly: aspInterfaceTypeLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5312314c189b4803, Typ: asp.Test.
---------------------------
OK
---------------------------

Hallo,

das instantieren erfolgt durch Aufruf des Konstruktors. Schau dir das mal hier an. Die haben mal Dotnet-Interop genutzt, damit der Excel-Buffer auch im RTC benutzbar ist. (Waschzettel gibt es u.a. hier.)

Im NAV2013 gibt es den Befehl ISNULL um DotNet- Variablen auf Vorhandensein zu prüfen (steht nicht in der Hilfe, mit F5 findest du Ihn unter System.Variable)

Gruß, Fiddi

Hallo,

das instantieren erfolgt durch Aufruf des Konstruktors. Schau dir das mal hier an. Die haben mal Dotnet-Interop genutzt, damit der Excel-Buffer auch im RTC benutzbar ist.

Kleine Korrektur: Excel Buffer funktioniert auch im RTC. Nur mit der Implementierung von DotNet geht es dann schneller als im CC. Im Standard ist ExcelBuffer im RTC grottenlangsam.

Zu Interop gab es 2011 auch diese Session bei den NAV TechDays
http://www.mibuso.com/dlinfo.asp?FileID=1399

Im Standard ist ExcelBuffer im RTC grottenlangsam.

Das meinte ich mit "benutzbar"

Gruß, Fiddi

Und so ist der ExcelBuffer im RTC performanter: http://blogs.msdn.com/b/nav/archive/201 ... n-rtc.aspx

Zum Thema Excel- Buffer:

Carsten hat sich zu dem Thema auch noch hier ausgelassen.
Mein Link von oben funktioniert in beide Richtungen (ohne den Umweg über CSV), und ist im RTC schneller als die normale CC- Lösung. Allerdings mit der Einschränkung, dass Sie nur im .XLSX- Format funktioniert.

Gruß, Fiddi

also ich hab noch mal eine Dll erstellt die nur ein Attribut hat und nichts macht außer getten und setten.

c# Code:

Code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace hallowelt
{
    public class hallowelt
    {
        private String answer = "";
        public String Answer
        {
            get { return answer; }
            set { answer = value; }
        }
    }
}


dann die NAV Funktion:

Code:

DotNetFunktion :=DotNetFunktion;
DotNetFunktion.Answer := 'bla bla bla';
MESSAGE(DotNetFunktion.Answer);

dann starte ich diese funktion und erhalte:

Code:

Microsoft Dynamics NAV
---------------------------

Diese Meldung richtet sich an C/AL-Programmierer: Eine .NET-Variable wurde nicht instanziiert. Es wird versucht, 'hallowelt.hallowelt.Answer' in 'CodeUnit TestDotNet' aufzurufen: OnRun
---------------------------
OK
---------------------------

Und hier noch die Fehlermeldung im Eventmanager:

Code:

Type: Microsoft.Dynamics.Nav.Types.Exceptions.NavNCLDotNetCreateException
SuppressMessage: False
FatalityScope: Call
Message: Diese Meldung richtet sich an C/AL-Programmierer: Es konnte keine Instanz des folgenden .NET Framework-Objekts erstellt werden: Assembly: hallowelt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fdd5c0be29d777be, Typ: hallowelt.hallowelt.
StackTrace:
     bei Microsoft.Dynamics.Nav.Types.NavAutomationHelper.GetTypeFromAssembly(String assemblyFullName, String typeName)
     bei Microsoft.Dynamics.Nav.Types.NavAutomationHelper.CreateDotNetObject(String assemblyFullName, String typeName, Object[] arguments)
     bei Microsoft.Dynamics.Nav.Runtime.NavDotNet.CreateDotNet(Object[] arguments)
Source: Microsoft.Dynamics.Nav.Types
HResult: -2146233088
----------------------------------
Type: System.IO.FileNotFoundException
Message: Die Datei oder Assembly "hallowelt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fdd5c0be29d777be" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
FileName: hallowelt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fdd5c0be29d777be
FusionLog:
  WRN: Protokollierung der Assemblybindung ist AUS.
  Sie können die Protokollierung der Assemblybindungsfehler aktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1 festlegen.
  Hinweis: Die Protokollierung der Assemblybindungsfehler führt zu einer gewissen Leistungseinbuße.
  Sie können dieses Feature deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.
 
StackTrace:
     bei System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
     bei System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
     bei System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
     bei System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
     bei System.Reflection.Assembly.Load(String assemblyString)
     bei Microsoft.Dynamics.Nav.Types.NavAutomationHelper.GetTypeFromAssembly(String assemblyFullName, String typeName)
Source: mscorlib
HResult: -2147024894


was interessant ist: Type: System.IO.FileNotFoundException

wieso findet er sie nicht? sie liegt im ...\Microsoft Dynamics NAV\70\Service\Add-ins auf dem Tier-Server und beim Client local auch.

was ist jetzt falsch? muss ich bei der DLL irgendetwas anderes machen? wie instanziiere ich denn eine Variable für NAV2013?

Ohne es böse zu meinen, aber nimm dir den Link von Kowa und schau es dir an. (Der ist richtig gut, und dort müsste es auch ein Link zu einem Projekttemplate geben, der die DotNet Interop direkt in NAV verfügbar macht) Es gibt auf MSDN oder anderen Community Seiten auch genug Doku/Guides zu DotNet Interop mit denen du schnell ans Ziel kommst ohne hier auf Antworten warten zu müssen.

In der Regel sind Kowa's Link(s) zu einem Post immer nützlich/empfehlenswert. (Meine Meinung!)

Du hast recht ich hab das Video von Kowas übersehen das tut mir leid, mal gucken ob es mir hilft. danke für den hinweis

Du hast recht ich hab das Video von Kowas übersehen das tut mir leid, mal gucken ob es mir hilft. danke für den hinweis

Der Vortragsredner Vjekoslav Babić hat in seinem Blog auch noch Beiträge zum Thema, z.B. Generics in .NET Interop for NAV 2013, wo man auch Fragen stellen kann. In Aktion bei der diesjährigen Konferenz kann man ihn hier sehen.

Mein Problem ist dass ich immer die Fehlermeldung bekomme:

Code:

Type: Microsoft.Dynamics.Nav.Types.Exceptions.NavNCLDotNetCreateException
SuppressMessage: False
FatalityScope: Call
Message: Diese Meldung richtet sich an C/AL-Programmierer: Es konnte keine Instanz des folgenden .NET Framework-Objekts erstellt werden: Assembly: hallowelt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fdd5c0be29d777be, Typ: hallowelt.hallowelt.
StackTrace:
     bei Microsoft.Dynamics.Nav.Types.NavAutomationHelper.GetTypeFromAssembly(String assemblyFullName, String typeName)
     bei Microsoft.Dynamics.Nav.Types.NavAutomationHelper.CreateDotNetObject(String assemblyFullName, String typeName, Object[] arguments)
     bei Microsoft.Dynamics.Nav.Runtime.NavDotNet.CreateDotNet(Object[] arguments)
Source: Microsoft.Dynamics.Nav.Types
HResult: -2146233088
----------------------------------
Type: System.IO.FileNotFoundException
Message: Die Datei oder Assembly "hallowelt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fdd5c0be29d777be" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
FileName: hallowelt, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fdd5c0be29d777be
FusionLog:
  WRN: Protokollierung der Assemblybindung ist AUS.
  Sie können die Protokollierung der Assemblybindungsfehler aktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1 festlegen.
  Hinweis: Die Protokollierung der Assemblybindungsfehler führt zu einer gewissen Leistungseinbuße.
  Sie können dieses Feature deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.
 
StackTrace:
     bei System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
     bei System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
     bei System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
     bei System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
     bei System.Reflection.Assembly.Load(String assemblyString)
     bei Microsoft.Dynamics.Nav.Types.NavAutomationHelper.GetTypeFromAssembly(String assemblyFullName, String typeName)
Source: mscorlib
HResult: -2147024894

Type: System.IO.FileNotFoundException

die dateien liegen auf dem Middel Tierserver unter "C:\Program Files\Microsoft Dynamics NAV\70\Service\Add-ins"
und beim Client ebenfalls im Add-In Ordner. In der Entwicklungsumgebung finde ich auch die DotNet Variable, aber wenn ich sie dann starten will kommt immer diese Meldung. also scheint er die DLL nicht zu finden aber wieso nicht sie liegt doch eindeutig in Addin Ordner??

Es ist nicht damit getan die DLL ins Addins- Verzeichnis zu kopieren, die muss Strong named sein, und im Assembly- Ordner unter Windows landen, da musst du dich mal bei Google/MSDN- schlau machen, wie man ein passendes Setup- Projekt anlegt.

Gruß, Fiddi

Also ich hab es nur im Addin Ordner aber
ich hab es mal test weise als x64 kompiliert komischerweise klappt es jetzt... aber ob das die Lösung ist?

Wenn es strong named ist, wird es wohl so sein, dass die Assembly automatisch richtig registriert und schon im GAC gelandet ist. Dann klappts auch in NAV.

Es ist wichtig das Du die Thematik verstehst und weißt was Du da tust.
Wenn ich den Beitrag hier so durchlese, habe ich ehrlich gesagt den Eindruck, dass Du Dich irgendwie "durchwurschtelst" und die Hälfte der Tipps von anderen Forenteilnehmern nicht wirklich beachtest.

Also die Lösung ist dass die dll für NAV 2013 als x64 kompiliert werden muss.

hab es extra nochmal quer getestet:

Situation: dll ohne strong named, nicht im GAC, gleiche Codeunite und gleiche Page

NAV 2009:
als x86 - Funktioniert
als x64 - Funktioniert nicht

NAV 2013:
als x86 - Funktioniert nicht
als x64 - Funktioniert

Ich habe zum selber testen beide Versionen angehängt.

Aufruf in der Codeunit:

Declaration: Demo DotNet <StaticDemo.Dynamics.'StaticDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'>

Code:

Demo := Demo.Dynamics;
Demo.Text := 'Test';
MESSAGE('%1',Demo.Text);

in der Customer Page habe ich lediglich eine Action angelegt die die Codeunit abruft.

edit:
Wichtig bei NAV2013 da man die DotNet Dll auch in der Entwicklungsumgebung benötigt muss man dort die x86 dll rein kopieren und nur für den Service die x64 benutzen. (etwas anstrengend dieses ständige um kompilieren)

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Ergänzend zu dem gelösten Thread

Erst ab NAV2013 gibts es sowas wie eine 64bit Lauffähigkeit.
Daher der Unterschied zwischen 2009 und 2013.

Dazu noch: http://techblog.byllemos.com/2008/10/writing-an-automation-for-navision-in-c/

Hier wird sehr schön erklärt wie man eine .Net geschriebene Assambly in NAV rein bekommt.