Debugging Com-freie Registrierung (C ++)

Question

Ich habe eine COM-Clientanwendung gebaut, die zwei COM-Server-DLLs verwendet. Ich möchte, dass diese Anwendung ohne COM-Registrierung ausgeführt wird - dh: WinSxs / .manifests

Ich bekomme eine Nachricht (... fast erwartet ...) "Klasse nicht registriert", wenn ich versuche, eine Instanz meines COM-Objekts von meiner Clientanwendung zu erstellen.

Ich bin bereits gelungen, dass diese Art von Konfiguration vorher, aber ich kann nicht herausfinden, warum dieses nicht fehlgeschlagen ist.

---

Hier sind noch ein paar Details:

• Die Module, die ich habe:
  • Ein MFC-Client, der von 2 COM-Servern abhängt (DLL1.DLL und DLL2.DLL)
  • dll1.dll com Server hängt von dll2.dll ab
  • dll2.dll hat keine com-abhängigkeit

    Die COM-Objekte, die ich habe:

    • in dll1.dll (.idlsprache)

      - generasacodicetagpre.

      -

      • in dll2.dll

        - generasacodicetagpre.

        -

        • der Client-Anruf

          - generasacodicetagpre.

          -

          • der client.exe.2.manifest

            - generasacodicetagpre.

            -

            ---

            Ich habe während der SXS-Aktivierungskontextgenerierung keinen Fehler: - Ein Fehler beim Windows-Protokoll (bedeutet, dass meine manifester Syntax korrekt ist) - Kein Fehler, der von SXstrace erkannt wurde (das Protokoll endet mit "Info: Aktivierungskontextgenerierung erfolgreich." Nachricht und enthält keinen Fehler oder eine erfolgreiche Nachricht. Außerdem sehe ich, dass mein Manifest richtig geladen ist)

            jede idee?

            Gibt es eine Möglichkeit, SXS tiefer zu debuggen, der mit sxstrace tiefer ist? Erhalten Sie zum Beispiel die Liste der eigentlichen registrierten COM- oder CLR-Klassen ???

            Vielen Dank nach Voraus

Answer 1

There are usually - at least - two manifests involved when building the activation context for registration free COM.

There is the EXE manifest, that specifies its dependent assemblies, including the assembly containing the COM components, and there is the assembly manifest, describing the dll's, window classes, and COM objects in the assembly.

This Blog contains information about what the .2 means. Basically, when the system looks for a manifest, it looks for modulename.exe[.resid].manifest - In the case that resid is 1, it is omitted.

So, you are using MFC, which means DevStudio, which means that your project should already be configured to produce a RT_MANIFEST resource automatically with the c-runtime and common control 6 settings in it.

Visual Studio 2005 supports this syntax to merge dependentAssembly elements with your applications manifest without having to try and merge XML directly:

#pragma comment(linker, \
    "\"/manifestdependency:type='Win32' "\
    "name='client' "\
    "version='1.0.0.0' "\
    "processorArchitecture='*' "\
    "language='*'\"")

So, if you add that to a cpp or header in your .exe, and then save your client.exe.2.manifest as "client.manifest", you should be all systems go.

Answer 2

The simple explanation is that the .manifest file isn't being used. Which is highly likely in this scenario, your .exe almost certainly already contains a manifest, embedded as a resource. Very common for a MFC app to enable visual styles. And for code compiled by the VS2005 or 2008 compilers which embeds a manifest to find the runtime DLLs.

To verify this, use File + Open + File and select the compiled .exe file. Look for the RT_MANIFEST node. If Windows finds such an embedded manifest it isn't going to continue looking for a file-based one. You need to merge your regfree COM entries into the embedded one. I wish I could give you a good MSDN Library link but the docs about manifests suck serious rock.