2009-05-19 21 views
16

Ho un oggetto COM 2.0 .NET che viene utilizzato da VBA in Excel. Funziona benissimo sulla mia macchina dev, ma quando provo ad usarlo su una workstation VM pulita ottengo questo errore:Excel .NET COM - Errore di automazione. Il sistema non riesce a trovare il file specificato

Errore di automazione. Il sistema non riesce a trovare il file specificato.

La DLL è registrata con "regasm/tlb/codebase mycom.dll" e non inserita nel GAC. Non ho diritti di amministrazione sulla casella della VM

Qualche idea?

risposta

13

È necessario richiamare il regime con il percorso completo dell'assieme come valore del parametro codebase o inserire l'assieme in un percorso che si trova sempre sul percorso per la ricerca delle librerie. Altrimenti non verrà trovato quando il client tenta di creare un'istanza dell'oggetto COM.

+0

Ho provato a utilizzare il regasm sul percorso completo dell'assembly che si trova in c: \ temp, ma ancora lo stesso errore – ingt

+1

Quindi immagino che la soluzione migliore sia avviare ProcessMonitor - http://technet.microsoft.com /ru-ru/sysinternals/bb896645.aspx - e guarda quale file non è stato trovato esattamente. Potrebbe essere un assembly dipendente di cui non sei affatto a conoscenza. Una volta che sai per certo che sarà molto più facile da risolvere. – sharptooth

+1

sharptooth, grazie * molto * molto per questa risposta. Ha salvato la mia pelle oggi! –

7

Su Windows 7, 64 bit e una DLL di framework .NET 4.0 (32 bit) che desidero essere utilizzabile come oggetto COM per un'applicazione VBA di Microsoft Excel 2010, ecco cosa ha funzionato per me.

  1. Copiare la DLL in C: (../TLB :.) \ windows \ syswow64
  2. In un guscio di cmd, eseguire

    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 
    

Si può saltare l'ultima parte se non si desidera o si ha bisogno di intellisense sulla macchina su cui si sta registrando l'assemblaggio.

Il blocco della chiave che ho avuto è che su XP non ho mai dovuto usare il parametro/codebase prima, ma quella era la cosa chiave necessaria prima che funzionasse.

3

Ho ricevuto questo errore "Errore di automazione. Il sistema non è stato in grado di trovare il file specificato" dopo aver creato un file .dll .NET (v4.0) con l'intenzione di utilizzarlo in un'applicazione VB6 (decorato la mia classe con " Attributi ClassInterface "e" ComVisible ", metodi con" ComVisible ").

Ho eseguito "regasm.exe -tlb C: \ PathTo \ MyDll.dll" ma ho ricevuto l'errore sopra riportato dopo aver aggiunto il file .tlb come riferimento nella mia applicazione VB6 ed eseguito/debuggandolo. Solo dopo aver aggiunto il parametro "-codebase" alla chiamata regasm.exe e aver aggiunto nuovamente il riferimento .tlb, l'errore è stato risolto.

Ho solo pensato di condividere la mia esperienza.

0

Ho anche ricevuto un errore di automazione. Il mio riferimento (in MS Access) era per un file TLB. Il file DLL corrispondente mancava dalla cartella che conteneva il file TLB e questo faceva apparire il messaggio 'errore di automazione'. Aggiungendo la DLL in modo fisso.

0

Stavo ottenendo lo stesso errore (non poteva consumare l'oggetto .NET dal legacy VB6 cod su una seconda macchina di sviluppo, dopo che stava lavorando su una prima macchina in cui l'avevo originariamente scritto). La DLL .NET è stata compilata e registrata correttamente - ho provato tutti i tipi di combinazioni - con e senza l'impostazione di build "Registra per COM Interop" in VS; registrarsi manualmente tramite regasm.exe e provare questo con e senza il parametro/codebase; ho provato sia a abilitare che a sopprimere l'attributo COM Visible level-level (durante la soppressione, ho impostato l'attributo sulla classe che ho bisogno di utilizzare da COM). Ma niente ha funzionato, ho continuato a ricevere lo stesso errore.

Risulta che ho aggiornato l'output DLL su .NET 4.5 sulla seconda macchina, mentre originariamente stava creando un assembly .NET 2.0. Il mio progetto aveva alcuni riferimenti a DLL Interop di terze parti che eseguivano .NET 2.0. Quando ho aggiornato questi riferimenti e ho ricreato la DLL -o-- ho ripristinato il mio progetto su .NET 2.0 - il mio problema è stato risolto. Usando/codebase (che VS fa automaticamente) ho scoperto che non avevo bisogno di inserire la mia DLL nella directory dell'applicazione o in \ syswow64. Anche i documenti MSDN indicano che è necessario utilizzare un SN (nome sicuro) per l'assembly quando si utilizza/codebase, ma ho scoperto che non è necessario; riceverai semplicemente un avvertimento dallo strumento da riga di comando regasm.exe.

Il punto è, da un punto di vista di interoperabilità COM, fare attenzione alla versione runtime .NET delle proprie dipendenze rispetto a .NET Framework che si desidera utilizzare.

Problemi correlati