We are trying to load in SilverLight 5.0 component running in IE a COM-visible .NET object registration-free using the activation context API.
http://msdn.microsoft.com/en-us/library/ms973913.aspx
The SilverLight component is runnning as a trusted application in the browser as described in http://msdn.microsoft.com/en-us/library/gg192793(v=vs.95).aspx.
The object can be loaded in a stand-alone test application using the activation context API so the manifest is properly formed.
In SiverLight running inside the browser, the component loader DLL (loaded from AppData/LocalLow) creates and activates the activation context successfully but fails to load the COM-visible .NET object DLL from the AppData/LocalLow. The result is always "the file could not be found".
Does anyone have experience with SilverLight/COM in similar setup?
TIA
I filed a ticket with Microsoft and the suggested solution is a workaround for an actual activation context bug.
//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.
There is a bug in Registration-free COM when invoking .NET assemblies because of the binding search logic that does not look in the manifest location at all but only at the GAC and the bin path of the process.
According to Microsoft:
This error occurs because fusion probing is failing for the .NET assembly where the managed COM component is defined and implemented. The .NET runtime only probes for files relative to the exeuctable path or the Global Assembly cache. For Reg-Free managed COM Interop it ignores the root manifest path.
I hope this helps someone in the future.
