2010-08-31 24 views
5

Piszę aplikację o interfejs API Peachtree i muszę pracować z każdą wersją API. Niestety dll z Peachtree 2011 nie może wchodzić w interakcje z Peachtree 2010 i na odwrót, mimo że te dwie biblioteki dll są przechowywane w tym samym miejscu i działają z dokładnie tym samym kodem.Załadować dll COM w czasie wykonywania?

Pomyślałem, że powinienem móc odnieść się do biblioteki dll według jej ścieżki pliku, pozostawić konkretną wersję jako fałszywą, osadzić typy interopów na false i skopiować lokalną na false, a ona po prostu użyłaby dowolnej wersji maszyny, ale ja otrzymam błąd, kiedy to zrobię - "Wyjątek został zgłoszony przez cel inwokacji."

Czy istnieje sposób późnego związania biblioteki DLL, mimo że jest to COM?

Mogę dostarczyć próbki kodu, które mogą być przydatne, ale to raczej kwestia konfiguracji projektu niż cokolwiek innego.

EDYCJA: Dziękuję bardzo za pomoc. Znalazłem moje rozwiązanie na pytanie innej osoby i opublikowałem je tutaj.

+0

Zazwyczaj odwołuje DLL współdziałania w czasie kompilacji, a jeśli jest on obecny w systemie, to będzie załadować dll COM przy starcie. Czy jest więcej informacji w błędzie lub wewnętrzny wyjątek? Czy istnieje kod błędu (0xZZZZZZZZ)? Czy możesz połączyć śledzenie stosu, czy to daje zbyt dużo informacji o Twojej aplikacji? The Peachtree API, czy to COM, czy jest to DLL, który łączy się z COM? –

Odpowiedz

7

Późne wiązanie z obiektami COM wymaga NIE dodawania odwołania do biblioteki COM do projektu .NET. Zamiast tego należy użyć coś jak to do tworzenia obiektów COM:

Type type = Type.GetTypeFromProgID("Excel.Application") 
    object app = Activator.CreateInstance(type); 

Następnie będzie wiązać się z każdą wersją biblioteki COM przy starcie.

Aby uzyskać więcej informacji, patrz this article.

+1

oraz .net 4.0 można używać nowego typu 'dynamic' i mieć późniejsze wiązanie wywołania metody, eliminując potrzebę dodawania odwołania do typu http://msdn.microsoft.com/en-us/library/dd264736.aspx –

+0

Jedną rzeczą, którą chciałbym dodać, jest to, że gdy otrzymasz obiekt z instancji tworzenia, możesz rzucić go na odpowiedni typ interfejsu, więc nadal masz wiązanie statyczne, mimo że tworzenie jest spóźnione. – zumalifeguard

+0

Dzięki za pomoc. Twoje pomysły doprowadziły mnie na właściwą drogę. – Yoenhofen

0

jest to rozwiązanie

Compile a version agnostic DLL in .NET

W przypadku, gdy odwołuje się kiedyś umrze, kluczowe jest, aby obsłużyć zdarzenia AppDomain.CurrentDomain.AssemblyResolve jak poniżej. Zdarzenie uruchamiane jest za każdym razem, gdy wiązanie zespołu ulegnie awarii, więc można je rozwiązać samodzielnie, naprawiając konflikty wersji.

using System.Reflection; 

static Program() 
{ 
    AppDomain.CurrentDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e) 
    { 
     AssemblyName requestedName = new AssemblyName(e.Name); 

     if (requestedName.Name == "Office11Wrapper") 
     { 
      // Put code here to load whatever version of the assembly you actually have 

      return Assembly.LoadFile("Office11Wrapper.DLL"); 
     } 
     else 
     { 
      return null; 
     } 
    } 
} 
Powiązane problemy