2008-12-15 15 views
11

Mam zestaw .NET, który mam narażone na COM za pośrednictwem pliku tlb i instalatora, który rejestruje tlb. Ręcznie sprawdziłem, czy instalator działa poprawnie i czy klienci COM mają dostęp do biblioteki. Do tej pory, tak dobrze ...Czy można przetestować zestaw narażonych COM z .NET?

Jednak próbuję zestawić kilka zautomatyzowanych testów systemu, które sprawdzają, czy instalator działa poprawnie. W ramach tego zautomatyzowałem instalację na maszynie wirtualnej i chcę teraz wykonać pewne wywołania do zainstalowanej biblioteki COM, aby sprawdzić, czy działa ona poprawnie. Początkowo myślałem o napisaniu kilku testów w VB6, ale mam już duży zestaw testów napisanych w języku C#, które odwołują się do zestawu .NET. Miałem nadzieję, że będę mógł to zmienić, odwołując się do pliku .tlb, ale pojawia się błąd, gdy próbuję tego w VS2008:

Biblioteka typu "blah.tlb" ActiveX została wyeksportowana z zestawu .NET i nie można jej dodać jako odniesienie.

Czy mogę w jakiś sposób oszukać VS2008, aby dodać ten odnośnik, być może edytując plik tlb?

Googling nie wymyślił żadnych rozwiązań. Wszystko znalazłem jest artykuł Microsoft Connect stwierdzając, że jest to „By Design”: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=120882

+0

Kilka osób wspomniało o użyciu narzędzia tlbimp.exe. Jeśli spróbuję tlbimp.exe blah.tlb, pojawia się błąd: "Biblioteka typów została wyeksportowana z zestawu CLR i nie można jej ponownie zaimportować jako zespołu CLR." – Akash

Odpowiedz

12

The Closest Mam rozwiązanie to coś podobnego:

using System; 
class ComClass 
{ 
    public bool CallFunction(arg1, arg2) 
    { 
     Type ComType; 
     object ComObject; 

     ComType = Type.GetTypeFromProgID("Registered.ComClass"); 
     // Create an instance of your COM Registered Object. 
     ComObject = Activator.CreateInstance(ComType); 

     object[] args = new object[2]; 
     args[0] = arg1; 
     args[1] = arg2; 

     // Call the Method and cast return to whatever it should be. 
     return (bool)ComType.InvokeMember("MethodToCall", BindingFlags.InvokeMethod, null, ComObject, args)) 
    } 
} 

To nie jest bardzo ładne, ale myślę, że ma rację. Oczywiście można umieścić instancję ComObject w konstruktorze i zawijać pozostałe wywołania do obiektu, ale prawdopodobnie nie jest to konieczne dla kodu testowego.

+0

+1 dla metody Type.GetTypeFromProgID, może uzyskać COM rodzaj. Próbowałem tego, działa (ale czy istnieje praktyczna różnica w bezpośrednim dodawaniu odniesienia? Nie wiem). – peenut

+0

"methodCOM" w tym przykładzie powinno w rzeczywistości być zmienną "ComType". – glebd

-1

Korzystanie tlbimp.exe można wygenerować zespół z komponentu COM, który może być używany w kodzie .NET

+2

Nie, jeśli komponent COM został utworzony w języku C# lub innym .NET –

+2

-1 Powód taki sam jak komentarz: Nie, jeśli komponent COM został utworzony w języku C# lub innym .NET – peenut

0

powinny być w stanie utworzyć klasę opakowania do zainstalowanego komponentu COM za pomocą TLBImp, a następnie uruchom testy. Zasadniczo będziesz pisać zestaw .Net, instalując go w COM, a następnie testując w klasie wrapper, dzięki czemu twoje testy będą routowane tak, jakby zostały wywołane przez komponent COM

Powiązane problemy