Jak możemy pracować z biblioteką dll VB6 wywoływaną z aplikacji usługi okien wielowątkowych C#?

Question

Używam wielowątkowej usługi Windows, która musi wywołać dll VB6. Nie ma dokumentacji na temat tej biblioteki dll VB6, a ten starszy system obsługuje bardzo krytyczny proces biznesowy.

Po raz pierwszy (wątek 1º) ten plik dll działa dobrze. Ponieważ inne wątki wymagają dostępu, zaczynają dostarczać błędne wyniki.

Czytałem jeden faceci mówiąc:.

„Wystarczy być ostrożnym z jednej strony, jeśli używasz VB6 Twój model gwintowania będzie trzeba zmienić, aby wspierać apartamenty jeśli używasz wielowątkowe usługę VB. obsługuje tylko kilka jednowątkowych apartamentów, ale .NET działa w pełni swobodnie z gwintem normalnie.) Wątek wywołujący bibliotekę DLL VB6 musi być zgodny z biblioteką DLL. "

Inny facet z zespołu wpadł mi na pomysł, aby umieścić ten plik ddl w oddzielnej domenie aplikacji. Ale nie jestem pewien.

Jak możemy pracować z biblioteką dll VB6 wywoływaną przez aplikację usługi wielowątkowego C#?

Answer 1

Kiedy pojawiają się wątki, czy zapisujesz obiekty i używasz ich później w nowych wątkach? Jeśli możesz, twórz obiekty świeże dla każdego wątku. Mamy taką sytuację z biblioteką danych, której używamy. Jeśli utworzysz połączenie w jednym wątku, nie będzie można go użyć z innego wątku. Jeśli utworzysz nowe połączenie dla każdego wątku, działa dobrze.

Jeśli tworzenie obiektów jest powolne, spójrz na klasę ThreadPool i atrybut ThreadStatic. Threadpools wielokrotnie przetwarzają ten sam zestaw wątków w celu wykonania pracy, a ThreadStatic umożliwia utworzenie obiektu istniejącego tylko dla jednego wątku. np.

[ThreadStatic] 
public static LegacyComObject myObject; 

Gdy przychodzi żądanie, zamień go w zadanie i umieść w kolejce w puli wątków. Po uruchomieniu zadania sprawdź, czy zainicjowano obiekt statyczny;

void DoWork() 
{ 
    if (myObject == null) 
    { 
     // slow intialisation process 
     myObject = New ... 
    } 

    // now do the work against myObject 
    myObject.DoGreatStuff(); 
} 

Answer 2

This article on multithreading Visual Basic 6 DLL's zapewnia pewien wgląd. Mówi:

Aby ActiveX DLL projekt wielowątkowych, wybierz żądane opcje gwintowania na karcie Ogólne w oknie dialogowym Właściwości projektu.

This article mówi, że są trzy możliwe modele do wyboru:

One thread of execution 
Thread pool with round-robin thread assignment 
Every externally created object is on its own thread 

Zakładam, że domyślnym jest one thread of execution, i że jeden z pozostałych dwóch opcji musi być zaznaczona.

Answer 3

Czasami warto spojrzeć na to: linky

A oto fragment, który przykuł moją uwagę:

obiektów VB6 COM są obiekty STA, że środki muszą one działać na STA wątek. Utworzono dwa wystąpienia obiektu z dwóch wątków MTA, ale sam obiekt będzie działał na pojedynczym wątku (utworzonym przez COM (OLE)), STA , a dostęp z dwóch wątków MTA zostanie zebrany i zsynchronizowany. Powinieneś więc zainicjować wątki jako STA, tak aby każdy obiekt działał na jego własnym wątku STA bez marshaling, a ty będzie w porządku.

W każdym razie obiekty COM w stylu VB są zawsze STA. Teraz, aby zapobiec marszałkowemu układowi kanałów i przełączaniu wątków, musisz utworzyć instancje w zainicjalizowanych apartamentach STA. Należy również zauważyć, że po ustawieniu atrybutu [MTAThread] na Main, skutecznie zainicjować wątek główny jako MTA, podczas tworzenia wystąpień obiektów STA z wątków MTA COM utworzy oddzielny (niezarządzany) wątek i zainicjuje go jako STA (jest to nazywane domyślną stacją STA), wszystkie wywołania obiektów STA z wątków MTA będą sterowane (i będą powodować przełączanie wątków), w niektórych przypadkach wywołanie funkcji Idispatch wywoła błąd z powodu awarii sieci IP. Zaleca się stosowanie obiektów STA (a zatem VB6) tylko w zgodnych mieszkaniach.

Answer 4

Mówisz

biegnę wielowątkowy okna usług, które trzeba zadzwonić dll VB6. Nie ma dokumentacji dotyczącej tej biblioteki dll o nazwie VB6, a ten starsza wersja systemu obsługuje bardzo krytyczny proces biznesowy .

a jednocześnie mówisz

Po raz pierwszy (1º wątku), to dll wykonuje dobrze. Ponieważ inne wątki potrzebują dostępu do , zaczynają dostarczać błędne wyniki .

bym zrobić bardzo pewne, że Zarząd ma świadomość niepowodzenia widzisz ponieważ kod wspieranie krytycznego procesu biznesowego jest stary i nieudokumentowane i jest używany w sposób nigdy nie był przeznaczony do użytku i nigdy nie był testowany do użycia. Założę się, że to nigdy nie było testowane do użycia z .NET przed, prawda?

Oto moja propozycja, a ta jest podobna do czegoś ja faktycznie realizowanej:

VB6 DLL spodziewa się nazywać na jednym wątku. Nie zawieść! Po uruchomieniu usługi należy uruchomić wątek odpowiedniego typu (nie mogę powiedzieć, ponieważ świadomie zapomniałem wszystkiego o STA/MTA). Kolejkowanie żądań do tego wątku w celu uzyskania dostępu do biblioteki DLL VB6. Niech każdy taki dostęp przejdzie przez pojedynczy wątek.

W ten sposób, jeśli chodzi o bibliotekę DLL VB6, działa ona dokładnie tak, jak została przetestowana.

---

BTW, to trochę różni się od tego, co zaimplementowałem. Miałem serwis internetowy, a nie usługę Windows. Miałem DLL C, a nie VB6, i to nie było COM. Właśnie refaktoryzowałem cały dostęp do rzeczy w jedną klasę, a następnie umieszczam oświadczenia blokujące wokół każdej z publicznych metod.