Excel .NET COM - Automatisierungsfehler. Das System kann die angegebene Datei nicht finden

Question

Ich habe ein .NET 2.0 COM-Objekt, das von VBA in Excel verwendet wird. Es funktioniert gut auf meinem dev-Computer, aber wenn ich versuche, es auf einer sauberen VM-Arbeitsstation zu verwenden, erhalte ich diesen Fehler:

Automatisierungsfehler. Das System kann die angegebene Datei nicht finden.

Die DLL ist registriert mit "regasm/tlb/codebase mycom.dll" und nicht in den GAC. Ich habe keine Administratorrechte auf der VM-Box

Irgendwelche Ideen?

Answer 1

Sie müssen entweder regasm mit dem vollständigen Pfad zur Assembly als codebase Parameterwert aufrufen oder die Assembly an einer Stelle platzieren, die sich immer auf dem Pfad zum Durchsuchen von Bibliotheken befindet. Andernfalls wird es nicht gefunden, wenn der Client versucht, das COM-Objekt zu instanziieren.

Answer 2

Auf Windows 7, 64-Bit und einem .NET 4.0 Framework Dll (32 Bit), die ich als ein COM-Objekt für eine Microsoft Excel 2010 VBA-Anwendung verwenden möchte, hier ist, was für mich funktionierte.

1. Kopieren Sie die DLL C: (../TLB :.) \ windows \ syswow64

2. In einer cmd Shell laufen

   C:\Windows\Microsoft.NET\Framework\v4.0.<whatever you have>\regasm.exe c:\windows\syswow64\<name of dll> /codebase /tlb:c:\windows\syswow64\<name of dll minus '.dll'>.tlb 
   

Sie können den letzten Teil überspringen wenn Sie intellisense nicht auf der Maschine haben wollen oder wollen, auf der Sie die Baugruppe registrieren.

Der Schlüssel zum Aufhängen war, dass ich unter XP nie zuvor den Parameter/codebase verwenden musste, aber das war der Schlüssel, der benötigt wurde, bevor dies funktionierte.

Answer 3

Ich erhielt diese "Automatisierungsfehler. Das System kann die angegebene Datei nicht finden" Fehler, nachdem ich eine .NET DLL (v4.0) mit der Absicht erstellt hatte, es in einer VB6-Anwendung zu verwenden (dekoriert meine Klasse mit " Attribute ClassInterface "und" ComVisible ", Methoden mit" ComVisible ").

Ich lief "regasm.exe -tlb C: \ PathTo \ MyDll.dll", aber erhielt den obigen Fehler nach dem Hinzufügen der .tlb-Datei als Referenz in meiner VB6-Anwendung und Ausführen/Debuggen es. Erst nach dem Hinzufügen des Parameters "-codebase" zum Aufruf regasm.exe und erneutem Hinzufügen der TLB-Referenz wurde der Fehler behoben.

Nur dachte ich würde meine Erfahrung teilen.

Answer 4

Ich erhalte auch einen Automatisierungsfehler. Meine Referenz (in MS Access) war zu einer TLB-Datei. Die entsprechende DLL-Datei fehlte in dem Ordner, in dem sich die TLB-Datei befand. Dies führte dazu, dass die Fehlermeldung "automation error" angezeigt wurde. Hinzufügen der DLL zurück in behoben.

Answer 5

Ich bekam den gleichen Fehler (konnte das .NET-Objekt nicht aus dem alten VB6-Code auf einer zweiten Dev-Maschine konsumieren, nachdem es auf einer ersten Maschine gearbeitet hatte, wo ich es ursprünglich geschrieben hatte). Die .NET-DLL kompiliert und registriert - ich habe alle möglichen Kombinationen ausprobiert - mit und ohne die Build-Einstellung "Für COM-Interop registrieren" in VS; Manuelles Registrieren über regasm.exe und das Ausprobieren sowohl mit als auch ohne den Parameter/codebase; habe versucht, sowohl das COM-sichtbare-Assembly-Level-Attribut zu aktivieren und zu unterdrücken (wenn ich es unterdrücke, setze ich das Attribut auf die Klasse, die ich von COM konsumieren muss). Aber nichts hat funktioniert, ich habe immer den gleichen Fehler bekommen.

Es stellte sich heraus, ich hatte die DLL-Ausgabe auf .NET 4 aktualisiert.5 auf der zweiten Maschine, während es ursprünglich eine .NET 2.0-Assembly baute. Mein Projekt hatte einige Referenzen, die auf Interop-DLLs von Drittanbietern gerichtet waren, auf denen .NET 2.0 ausgeführt wurde. Wenn ich diese Verweise entweder aktualisierte und das DLL neu erstellte, oder mein Projekt zurücksetzte, um auf .NET 2.0 ausgeführt zu werden, wurde mein Problem gelöst. Bei der Verwendung von /codebase (was VS automatisch tut) stellte ich fest, dass ich meine DLL nicht in das Anwendungsverzeichnis oder in \ syswow64 setzen musste. Auch die MSDN-Dokumentation besagt, dass Sie einen SN (starken Namen) für Ihre Assembly verwenden müssen, wenn Sie/codebase verwenden, aber ich habe festgestellt, dass Sie nicht müssen; Sie erhalten nur eine Warnung vom Befehlszeilentool regasm.exe.

Der Punkt ist, aus Sicht von COM Interop, seien Sie vorsichtig mit der .NET-Laufzeitversion Ihrer Abhängigkeiten in Bezug auf das .NET Framework, auf das Sie abzielen.