none
Registration-free deployment of a managed C++ application client which uses 2 COM servers from 2 managed DLLs RRS feed

  • Question

  • Hi, I'm trying to use registration-free COM deployment in a configuration where I have a C++ client (exe) and 2 C# DLLs. Each DLL exposes 1 COM class with 1 method (this is just a simple test scenario). The 1st dll is named mysxs.dll with 1 method named Version() and 2nd is mysxs2.dll with 1 method Version2(). I've created a manifest for the client application (see below). The client calls Version() and then Version2() after creating instances of the appropriate COM classes. With manifest below it works as expected: I can see the result of the call to Version() (from mysxs.dll) fine and then I get an error "class not registered" for the 2nd call (to Version2()) since it cannot find mysxs2.dll. The problem is that I cannot figure out how to modify the manifest to include the 2nd DLL so that both calls would succeed. I tried all the combinations of dependentAssembly tags etc. to no avail. Most of the articles on the Web which I found show an example with 1 dependent DLL which works fine. Is there a way to have 2 DLLs exposing 2 COM classes in this configuration? Note that using tools like mt.exe or genman32.exe doesn't work (they complain about non-unique "name" element in assemblyIdentity if you try to merge 2 manifests from mysxs.dll and mysxs2.dll). Thanks in advance. Alex.

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

    <dependency>

    <dependentAssembly>

    <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

    </dependentAssembly>

    </dependency>

    <assemblyIdentity

    name="mysxs"

    version="1.0.0.0"

    publicKeyToken="1cb19d1cf0e42fd1"

    processorArchitecture="MSIL" />

    <clrClass

    clsid="{F3ED8372-A99E-4441-9613-1D3A1D971234}"

    progid="mysxs.MysxsClass"

    threadingModel="Both"

    name="mysxs.MysxsClass"

    runtimeVersion="v2.0.50727">

    </clrClass>

    <file name="mysxs.dll">

    </file>

    </assembly>

    Wednesday, February 11, 2009 6:04 PM

All replies

  • I don't get the problem.  You should just add another <dependentAssembly> for mysxs2.dll.  Of course, the name, version, clsid, progid and <file> must be different.
    Hans Passant.
    Wednesday, February 11, 2009 8:40 PM
    Moderator
  • Thanks for the reply. Yes, this is what I thought too. However, this doesn't work. If I add the 2nd dependency like this (see below) 
    I get an error (message box) "application failed to start because configuration is incorrect" with Event Viewer showing " "The element clrClass appears as a child of element urn:schemas-microsoft-com:asm.v1^dependentAssembly which is not supported by this version of Windows." I'm not sure what other syntax I can try.

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
            <dependency>
                <dependentAssembly>
                    <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' 
                                                 processorArchitecture='x86'         publicKeyToken='1fc8b3b9a1e18e3b' />
                </dependentAssembly>
           </dependency>

            <dependency>
                <dependentAssembly>
                    <assemblyIdentity name="mysxs" version="1.0.0.0" publicKeyToken="1cb19d1cf0e42fd1" processorArchitecture="MSIL" />
                        <clrClass clsid="{F3ED8372-A99E-4441-9613-1D3A1D971234}" progid="mysxs.MysxsClass" threadingModel="Both"
                                       name="mysxs.MysxsClass" runtimeVersion="v2.0.50727">
                        </clrClass>
                        <file name="mysxs.dll">
                        </file>
               </dependentAssembly>
            </dependency>

            <dependency>
                <dependentAssembly>
                    <assemblyIdentity name="mysxs2" version="1.0.0.0" publicKeyToken="6126635f76f9a39b" processorArchitecture="MSIL" />
                        <clrClass clsid="{F3ED8372-A99E-4441-9613-1D3A1D979087}" progid="mysxs2.MysxsClass2" threadingModel="Both"
                                       name="mysxs2.MysxsClass2" runtimeVersion="v2.0.50727">
                        </clrClass>
                        <file name="mysxs2.dll">
                        </file>
               </dependentAssembly>
            </dependency>

    </assembly>

    • Edited by alexbtr Friday, February 13, 2009 5:50 PM
    Friday, February 13, 2009 12:50 AM
  • Crud, that's hard to read.  Practice in the sandbox using the Format Code Block feature so the xml is properly indented.  Meanwhile, the obvious next question: what version of Windows?
    Hans Passant.
    Friday, February 13, 2009 1:49 AM
    Moderator
  • Sorry, I just copied this from VS2008 editor, and you're right, it is hard to read. Now I've edited it by hand and hopefully it looks better. Please let me know if I can improve it more (I'm not an XML guy and maybe missing some trick). As for the OS it is Windows XP Professional SP3. Thanks again.
    Friday, February 13, 2009 5:59 PM
  • According to the MSFT articles, you'll need to split the manifest across the client and the server.  The <clrClass> element goes in the manifest for the managed app.  Check this blog post and this MSDN article.  It looks pretty odd to me, let us know how it pans out.

    Hans Passant.
    Friday, February 13, 2009 8:04 PM
    Moderator
  • Thanks, these posts do look like most relevant to the problem. I tried it but unfortunately it didn't work and all I got is a nice helpful message in the Event Viewer: "Generate Activation Context failed for C:\devel\test\SideBySideRelated\sxstest\sidebysideclientcpp.exe.Manifest. Reference error message: The operation completed successfully." There must be something else here because my own manifest (see below) does work for 1 dependent assembly at the time and it doesn't look like the manifest suggested by Junfeng or MSDN article. The way I created this manifest is as follows:
    mt.exe -inputresource:sidebysideclientcpp.exe -out:sidebysideclientcpp.exe.manifest
    genman32 mysxs.dll
    This gave me 2 manifest files: sidebysideclientcpp.exe.manifest and mysxs.dll.manifest
    Then I edited 
    sidebysideclientcpp.exe.manifest by adding the contents of mysxs.dll.manifest. 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <
    assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
    >
        <
    dependency
    >
            <
    dependentAssembly
    >
                <
    assemblyIdentity type="win32name="Microsoft.VC90.DebugCRTversion="9.0.21022.8" processorArchitecture="x86

                                            publicKeyToken="1fc8b3b9a1e18e3b"
    >
                </
    assemblyIdentity
    >
            </
    dependentAssembly
    >
        </
    dependency
    >

        <assemblyIdentity name="mysxs" version="1.0.0.0" publicKeyToken="1cb19d1cf0e42fd1" processorArchitecture="MSIL" />
            
    <
    clrClass
                
    clsid="{F3ED8372-A99E-4441-9613-1D3A1D971234}" progid="mysxs.MysxsClass

                        threadingModel
    ="Both
        name="mysxs.MysxsClass" runtimeVersion="v2.0.50727">

            </clrClass>
            
    <
    file name="mysxs.dll"
    >
            
    </
    file
    >

    </
    assembly
    >

     There are other ways to create these manifests (like using Visual Studio IDE to get the separate manifest files for the exe and the dll) but I can't figure out how to combine 1 exe manifest and 2 dll manifests (mysxs.dll.manifest and mysxs2.dll.manifest) so that the client can use both dlls. The 2nd DLL manifest is of course from mysxs2.dll and it looks identical to mysxs.dll.manifest except for the name etc. 
    Note that I also tried embedding the manifests in the exe and it has the same effect as using separate manifest file. Interestly enough, you can embed exe manifest as the resource #1 and DLL manifest as the resource #2 but looks like there is no way to embed the 2nd DLL (resource #2 can serve only 1 DLL).

    Friday, February 13, 2009 11:52 PM
  • Hello  Hans,
    Is there anything else which can be done to use side-by-side in my environment? Thanks.
    Tuesday, March 10, 2009 5:53 PM