Automation kann nicht instanziert werden

Hallo,

ich habe im Moment einen Kunden, der meine Automation nutzen möchte.
Bisher hatten wir mit der Automation keine Probleme und alles lief enwandfrei.

Doch der aktuelle Kunde kann die Automation zum Teufel nicht aufrufen. Es kommt die Standard Fehermeldung.
Ich habe also die GUID geändert und die Version erhöht um die Automation in NAV unterscheiden zu können.

Sie wird mir im Object Designer korrekt angezeigt.

Doch jedes mal wenn wir die Automation aufrufen, kommt der Fehler.
Hab versucht die Situation zu simulieren und habe keine Probleme.

Gibt es vielleicht Komplikationen mit den Rechten unter Windows 7?
Wir haben schon versucht den CC als Admin auszuführen. Das hatte aber auch nicht den gewünschten Effekt.

Bin dankbar für jeden hilfreichen Tipp

Gruß

Die Frage ist was macht Deine Automation? Win7 ist pingelig, was Schreibzugriffe im Programme-Ordner angeht. Benutzt Dein Programm vielleicht Temp-Dateien? Außerdem hätte Win7 gerne signierte DLL's. Und die Frage ist Deine DLL auch richtig registriert?

Volker

Hallo,

meine Automation macht nichts anderes als auf meinem Windows 7 System auch;-) Und da läuft es wunderbar. Genauso wie bei anderen Kunden auch. Ich habe beim Kunden mittlerweile die UAC komplett ausgeschaltet. Führte allerdings zu keinem Ergebnis.

Zwar stelle ich in der Automation eine Verbindung zu einem WebService her(der hat nichts mit NAV zu tun) und ja, ich erstelle auch eine Datei..Aber das kann doch nicht die Lösung sein. Immerhin komme ich gar nicht bis zu dieser Stelle! Schon beim CREATE tritt der Fehler auf. TEMP Data nutze ich allerdings nicht.

Signierte DLL`s? Das ist mir nur bei Treiber bekannt. Dort wird seit Vista und nachfolgenden 64bittigen Systemen eine Signatur verlangt(die auch nicht gerade billig ist).
Naja, versuchen kann man es ja trotzdem. Sehe gerade, dass das nicht so ein Aufwand ist.

Ja, die DLL wird korrekt registriert. Ansonsten gehe ich davon aus, dass ich sie nicht mal im Object Designer sehen könnte.
In der regel registrieren wir mit "regasm" oder "regsvr32". Beide Methoden habe ich mit dem Kunden ausprobiert.
Führte aber auch zu keiner Lösung.

Mir ist jedoch aufgefallen, dass der Kunde(angeblich hätte er da ja nichts umgestellt;-) ) sehr wenig Dienste laufen hat. der COM+ Dienst und seine Anhängsel liefen beispielsweise gar nicht. Nachdem diese Dienste gestartet wurden hat sich allerdings immer noch nichts getan. Habe auf meinem System mal beide Dienste einfach abgestellt und auf "deaktiviert" gestellt. Automation wurde trotzdem gefunden.

Ich weiß nicht welche Dienste da noch mit drinhängen oder ob überhaupt ein Dienst laufen muss, um .NET DLL`s von NAV aus heraus auszuführen.


Gruß

Hallo,

dumme Frage: reden wir von Classic oder RTC?
Von wegen dem Installationsort wg. Middle- Tier usw.

Gruß, Fiddi

Classic Client

Und deine DLL liegt auch im Verzeichnis C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic, C:\Program Files\Microsoft Dynamics NAV\60\Classic bzw. der deutschen Entsprechung?
Ist auch für COM registriert (regsvr32 für non .NET., regasm für .NET DLLs)?
Alle abhängigen DLLs, also DLLs die die Instanziierte DLL benötigt liegen ebenfalls im Zugriff (Classic Verzeichnis)?

Ja, DLL wurde im Ordner der gestarteten finsql.exe abgelegt.
Registriert wurde mit regasm und, weil wir ganz sicher gehen wollten, regsvr32. Jedoch nicht total wild. Sondern immer brav ein "register" und dann ein "unregister" und dann wieder ein "register" usw...
Abhängige DLL`s liegen nicht im Ordner. .NET ist selber in der Lage die DLL`s nachzuladen. In was für einer Welt würden wir leben wenn ich jetzt auch noch den halben Kern des .NET Frameworks ins das Verzeichnis schieben müsste;-)
Es handelt sich um eine .NET Automation die auch für COM Interop registriert wurde(was meines Wissens nach nur auf der Entwickler Maschiene von nöten ist). Wurde jedoch erledigt.

Hallo Teddy,

ja, schon klar, dass das Framework auch im Zugriff ist, wenn die DLLs nicht im Client-Verzeichnis liegen :)

Ich meinte eher die DLLs die im VS als Referenz angegeben sind und NICHT zum Framework gehören, ob diese auch alle im Zugriff liegen. Gute Kandidaten dafür sind solche DLLs wie die Interop.MSXML2.dll oder ähnliche.

Alternativ kannst du die DLL bzw. den Sourcecode mal hier posten.

Hallo,

also es sind keine Referenzen im Einsatz, die nicht .NET spezifisch sind. Knn dir trotzdem mal eine Liste geben:

System
System.Core
System.Data
System.Data.DataSetExtensions
System.XML
System.XML.Linq

Ist aber eigentlich nichts wildes dabei.

Was das posten der DLL angeht..Also das darf ich natürlich nicht;-) Sonst würd ich hier was auf den Sack bekommen. Jedoch kann ich dir aber mal den Grundaufbau zeigen(der ja auch bei den anderen Kunden funktioniert);-)

Code:

    [Guid("7EE73BCD-224B-4e84-A1A0-F1DA4881E519")]
    public interface GOB_VAT_Checker_Interface
    {
         //Meine Methoden und Eigenschaften
    }

    [Guid("F42DE9DC-7CFC-4655-A2BA-6FE39EA29669")]
    [ClassInterface(ClassInterfaceType.None)]
    public class VATChecker : GOB_VAT_Checker_Interface
    {
         //Meine Methoden und Eigenschaften
    }


Zudem wurde in den Projekteigenschaften unter "Anwendung-> Button "Assemblyinformationen"-> GUID" eine neue GUID hinterlegt. Außerdem zählen wir die Versionen hoch um sie im Object Designer unterscheiden zu können.

Und der Haken bei "Assembly COM-sichtbar machen" wurde auch gesetzt. Also falls das noch nicht klar war;-)

Und ich muss mittlerweile ganz ehrlich sagen..Ich glaube nicht, dass das was mit meiner geilen Programmierung(:-) ) zu tun hat sondern da ist was anderes im Busch. Ich hab hier bei uns schon 2 Maschinen mit Win7 mit dieser Automation bestückt und das lief reibungslos.

Ich habe den Kunden jetzt angewiesen, das mal auf 1-2 anderen Maschinen bei ihm im Haus zu installieren, damit wir eine fehlerhafte Programmierung ausschließen können. Jedoch hat der sich noch nicht gemeldet. Ich bin mal gespannt was da rauskommt.