Rejestracja Free Com i manifestów dll

Question

Próbuję skonfigurować rejestrację wolną COM, ale mam niewielki problem w tym, że inny obiekt COM może być klientem.

App.exe -----> COM Server/Client DLL (zarejestrowany czy nie) --------> COM Server DLL (nie zarejestrowany)

Moje pytania jest to możliwe utworzyć manifest dla drugiej biblioteki dll (COM Server/Client dll)? Nie mam kontroli nad plikiem wykonywalnym, ale jeśli tak, to działa, jeśli utworzę manifest klienta dla pliku wykonywalnego i manifest serwera dla biblioteki dll COM.

to plik manifestu dla średniej dll. Próbowałem go osadzić i wypróbowałem na zewnątrz. Nadal nie działa.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    <assemblyIdentity type="win32" 
        name="COMCliSer.dll" 
        version="1.0.0.0" 
    /> 
    <dependency> 
    <dependentAssembly> 
     <assemblyIdentity 
        name="COMSer.dll" 
        version="1.0.0.0"      
     /> 
    </dependentAssembly> 
    </dependency> 
</assembly> 

Na dalszych badań, mogę to wszystko działa tak długo, jak dll środku jest również rejestracja za darmo i exe ma manifestu aplikacji. Jak tylko zarejestruję środkową bibliotekę DLL i zrzucę manifest aplikacji (nie mam kontroli nad tym, co exe będzie używać mojej biblioteki DLL), cała sprawa przestanie działać.

Jeśli plik exe nie ma manifestu, manifest dll nie jest brany pod uwagę. Mogę to udowodnić, ustawiając wszystko do pracy. Następnie popełniam błąd w manifeście montażowym. Wyskakuje zwykła wiadomość:

Nie można utworzyć procesu: Uruchomienie tej aplikacji nie powiodło się, ponieważ konfiguracja aplikacji jest niepoprawna. Ponowne zainstalowanie aplikacji może rozwiązać ten problem.

Gdybym wtedy upuść manifestu aplikacji, ładowania aplikacji (aczkolwiek w CoCreateInstance nie powiedzie, ponieważ zależności nie są brane pod uwagę)

Answer 1

Wystarczy dodać zależność montażową do serwera/manifeście klienckiego DLL, który wskazuje na com dll serwera.

Należy pamiętać, że manifesty zespołu różnią się od manifestów "aplikacji": manifest zespołu opisuje zespół: nadaje mu nazwę i wyświetla listę bibliotek dll. Manifest aplikacji to zasób osadzony RT_MANIFEST, który opisuje zależności bieżących modułów.

Tak więc, w ostatecznym rozrachunku, to masz:

• app.exe, z zewnętrznym (app.exe.manifest) lub wbudowanego RT_MANIFEST opisujący zależność od zespołu o nazwie „acme.clientserver”
• acme.clientserver.manifest opisujący zespół i listing "clisrv.dll" jako rejestracja wolna com dll.
• clisrv.dll z zewnętrznym (clisrv.dll.2.manifest) lub osadzony RT_MANIFEST, opisującym zależność od zespół zwany „acme.server”
• acme.server.manifest, opis zespołu, wymieniając Serv .dll jako rejestracja wolna com dll.
• serv.dll - który może, ale nie musi, zawierać listę zawierającą bardziej zależne złożenia.

Technicznie możliwe jest wywołanie zestawu przez nazwę biblioteki DLL i scalenie razem zespołu i manifestu biblioteki DLL - obsługuje go program ładujący win32, ale niektóre ustawienia obowiązujące w manifestach aplikacji nie są poprawne w manifestach zespołu , co może spowodować, że wynikowy montaż nie zostanie załadowany. To także sprawia, że ​​bardzo trudno jest podpisać cyfrowo.

---

WRT exe musi mieć manifest: Zazwyczaj manifest exe określa domyślny kontekst aktywacji procesów. Nie jestem w 100% pewien, jak zachowuje się okno, gdy exe nie ma manifestu, ale jestem prawie pewien, że manifesty w bibliotekach DLL będą nadal przetwarzane.

Co oznacza, że ​​problem sprowadza się do braku obsługi izolacji w CoCreateInstance - z jakiegoś powodu - domyślnie - CoCreateInstance wyszukuje tylko domyślny kontekst aktywacji dla wpisów COM.

Sposób przesłonić to ręcznie zbudować własny kontekst aktywacyjny, używając Activation Context API

Podstawową metodą byłoby zadzwonić:

• CreateActCtx - stworzenie kontekstu aktywacji od DLL oczywistych .
• AktywacjaActCtx - w celu aktywacji kontekstu
• CoCreateInstance - przeszuka bieżący kontekst aktywacji dla wpisów w komendach darmowych reg.
• DeactivateActCtx - aby przywrócić domyślny kontekst aktywacji.

Możesz dodać/D ISOLATION_AWARE_ENABLED zawinąć większość połączeń okien, które są dokonywane przez kontekstach aktywacyjnych, z jakiegoś powodu nie jest owinięty CoCreateInstance:/