none
registration free COM/Interop with SilverLight RRS feed

  • Question

  • I am trying to activate a COM-visible .NET assembly using the activation context API from SilverLight using the following configuration:

    IE ->

    SilverLIght component ->
    AssemblyLoader.dll -
                    unmanaged (not-COM)
                    [manifest with dependency on AssemblyDLL's manifest] ->                                                                                                                                                                                                 AssemblyNET.dll (COM visible)[manifest]

    The SilverLight component is running as a trusted application in the browser as described here http://msdn.microsoft.com/en-us/library/gg192793(v=vs.95).aspx.

    The manifests are not embedded. The activation context succeeds by loading the AssemblyLoader.dll.manifest but the result from CoCreateInstance of any object from AssemblyNET.dll is always 

    hr 0x80070002 The system cannot find the file specified.

    I can successfully call the CoCreateInstance in the following configuration:

    Test.exe using the AssemblyNET.dll.manifest to create the activation context -> AssemblyNET.dll (COM visible)[manifest]

    Is this kind of activation context setup possible?




    • Edited by r_georgi Tuesday, August 13, 2013 6:59 PM
    Monday, August 12, 2013 8:33 PM

All replies

  • Hello,

    Welcome to MSDN forum.

    From your description, I know that you encounter some issue about Registration-Free COM Interop with Silverlight, i'm not sure that if you have used Dynamically load Assemblies ,When loading the DLL as a Stream into the AssemblyPart, you can create an Assembly at the same time,you can do like this :

               AssemblyPart ap = new AssemblyPart();
             
    Assembly a = ap.Load(s);

    The Assembly will then allow you to create an object:

              Canvas can = (Canvas)a.CreateInstance("MyAssembly.MyClass");

    In addition,  I would like to suggest you to refer this  articles:

    Fuslogvw.exe (Assembly Binding Log Viewer) that displays details for assembly binds. This information helps you diagnose why the .NET Framework cannot locate an assembly at run time.

    Hope these help.


    Lilia Gong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.



    Tuesday, August 13, 2013 3:24 AM
    Moderator
  • Hi Lilia,

    Our loader is unmanaged code (C++) so I am not sure if this approach applies in our scenario.

    Thanks

    Tuesday, August 13, 2013 1:42 PM
  • Hello,

    Thanks for your reply.

    From your description,I think that  you need to  offer us your manifest files and how to deploy .

    In addition,I would like to suggest you to  refer this article:  Registration-FreeCOM Interop that activates a componentwithout using the Windows registry to store assembly information. Instead of  registering a component on a computer during deployment, you create Win32-style manifest files at design time that contain information about binding and activation .

    Hope these help.


    Lilia Gong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, August 14, 2013 9:41 AM
    Moderator
  • Hi Lilia,

    I am familiar with the article you mention and we have followed the manifest creation described without any success. I was able to generate a manifest using mt.exe with the tlb option that sort of helped - I was able to load the the COM visible .NET assembly but I am getting an error 0x800401f9 Error in the DLL when I call CoCreateInstance. The .NET assembly does not have DllGetClassObject implemented. So I reverted back to the manifest generated from the managed assembly as per the MSDN article.

    dll loader manifest:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
       <assemblyIdentity version="1.0.0.0" name="adapterSxSDLLClient" type="win32" />
        <dependency>
            <dependentAssembly>
                <assemblyIdentity name="adapterNET" version="1.0.0.14" publicKeyToken="db556b00b05f583b" processorArchitecture="x86"/>
            </dependentAssembly>
        </dependency>
    </assembly>

    and the assembly manifest as per the article:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <assemblyIdentity name="adapterNET" version="1.0.0.14" publicKeyToken="db556b00b05f583b" processorArchitecture="x86"></assemblyIdentity>
        
        <clrClass> ...</clrClass>
        <clrClass> ...</clrClass>
        
        <file name="adapterNET.dll" hashalg="SHA1"></file>
    
    </assembly>

    The bottom line is:

    1. The .NET COM-visible assembly can be loaded successfully if the executable is in the same folder.
    2. The .NET COM-visible assembly can NOT be loaded successfully if the executable is NOT in the same folder.

    Thank you very much for your help.

    • Edited by r_georgi Thursday, August 15, 2013 1:48 PM
    Wednesday, August 14, 2013 8:30 PM
  • I have filed a support incident with Microsoft regarding this issue. Will update with any findings along the way.
    Monday, August 19, 2013 1:52 PM
  • The Microsoft support suggested a workaround:

     //Create your own activation context pointing to the manifest
    
    ACTCTX actCtx;
    
    ULONG_PTR pCtxCookie;
    
    //initialize actCtx with your manifest name and path
    
    ....
    
    HANDLE hActCtx = CreateActCtx(&actCtx);
    
    ActivateActCtx(hActCtx, &pCtxCookie);
    
    ....
    
    //surround EVERY CALL to CreateInstance with the null activation context, otherwise you will get an error on DeactivateActCtx!!!
    
    ULONG_PTR cookie; //do not reuse the pCtxCookie!!!
    
    ActivateActCtx(NULL, &cookie);
    HRESULT hr = classA.CreateInstance(__uuidof(SxSNET::SxSClass));
    
    DeactivateActCtx(0, cookie); //deactivate the null context
    
    ...
    
    //deactivate and deallocate your actual manifest based activation context
    
    DeactivateActCtx(0, pCtxCookie);
    
    ReleaseActCtx(hActCtx);
    

    The solution does NOT work. The problem with this solution is that the null context forces the binding to the registered version of the .NET assembly not the one using the isolated context.

    Wednesday, August 21, 2013 5:22 PM