Q: Hi,
I need to reliably redirect an applications look up of a specific DLL. Using the app.exe.local approach does not work because local files are ignored if the application has a manifest (embedded or separate file). So I am trying to do DLL redirection by defining the DLL as a private assembly in the manifests. (more..) A: Ok, you need to set it up like this: * c:\apppath\testapp.exe - your test apps exe file
* c:\apppath\testapp.exe.manifest - the - potentially embedded application manifest file
* c:\apppath\< emptyassm\ >emptyassm.manifest - A manifest describing your new assembly.
* c:\apppath\< emptyassm\ >empty.dll - the assembly dll
* c:\apppath\< emptyassm\ >empty.dll.2.manifest - the embedded manifest in the dllSo, you have your test application which contains an application manifest: which contains dependent assembly references for the app - including one you add to your custom dll assembly. In the application folder you have the assembly manifest of the "emptyassm" assembly, which contains a file node referencing the actual dll, "empty.dll".empty.dll embeds its own manifest, containing dependent assembly references on any public or private assemblies it requires. This is the important point: the "emptyassm" assembly manifest, and the "empty" dll manifests are potentially different. The assembly's manifest file MUST NOT be embedded, but might share the dll manifest name IF you choose to name your manifest by the name of the dll. Now, when the loader loads your EXE, it loads your EXE's manifest and adds it to the activation context. When the EXE's import table is processed, OR you call LoadLibrary, the loader first searches the activation context for an assembly manifest with a matching file node. If it finds a matching assembly, THEN it processess and loads the dll from the assembly location (the folder containing the assemblies .manifest) and it may, at this time, if there is no embedded manifest in the dll AND the dll and manifest have the same name, reuse the same manifest file to setup the dll's activation context. Read more: StackOverflow
I need to reliably redirect an applications look up of a specific DLL. Using the app.exe.local approach does not work because local files are ignored if the application has a manifest (embedded or separate file). So I am trying to do DLL redirection by defining the DLL as a private assembly in the manifests. (more..) A: Ok, you need to set it up like this: * c:\apppath\testapp.exe - your test apps exe file
* c:\apppath\testapp.exe.manifest - the - potentially embedded application manifest file
* c:\apppath\< emptyassm\ >emptyassm.manifest - A manifest describing your new assembly.
* c:\apppath\< emptyassm\ >empty.dll - the assembly dll
* c:\apppath\< emptyassm\ >empty.dll.2.manifest - the embedded manifest in the dllSo, you have your test application which contains an application manifest: which contains dependent assembly references for the app - including one you add to your custom dll assembly. In the application folder you have the assembly manifest of the "emptyassm" assembly, which contains a file node referencing the actual dll, "empty.dll".empty.dll embeds its own manifest, containing dependent assembly references on any public or private assemblies it requires. This is the important point: the "emptyassm" assembly manifest, and the "empty" dll manifests are potentially different. The assembly's manifest file MUST NOT be embedded, but might share the dll manifest name IF you choose to name your manifest by the name of the dll. Now, when the loader loads your EXE, it loads your EXE's manifest and adds it to the activation context. When the EXE's import table is processed, OR you call LoadLibrary, the loader first searches the activation context for an assembly manifest with a matching file node. If it finds a matching assembly, THEN it processess and loads the dll from the assembly location (the folder containing the assemblies .manifest) and it may, at this time, if there is no embedded manifest in the dll AND the dll and manifest have the same name, reuse the same manifest file to setup the dll's activation context. Read more: StackOverflow