This question has been asked before on SO for example here and here. The scenario is that one wants to use a COM component in their application without having to register the COM component on the machine. This is accomplished by adding two manifest files one to the client and one to the server and the side by side feature of the OS takes care of the rest. Now this works fine when all Dlls are in the same folder.
In my specific scenario, I'm trying to have a legacy .net 2.0 dll access a 4.0 dll. We don't want to change the 2.0 dll and with the above method I was able to accomplish this. However, if the 4.0 dll is in a subfolder of the executable(the 2.0 dll). The 4.0 dll is not found when side by side execution kicks in. I'm currently calling into the win32 API and creating a new ActivationContext passing in the manifest files. I used ProcMon and saw that the dll is being looked for in the executable directory and not in the path specified in the manifest for lookup. As the links above also attest it seems that .net is only aware of the ClrClass in the manifest and ignores the AssemblyLocation supplied for private assembly lookup which is veeery unfortunate !
Anyways, the workaround in the above links are GAC and AssemblyResolve. I don't want to go through GAC if possible and AssemblyResolve wouldn't work for me as I would have to subscribe to it in the 2.0 dll which can't load the 4.0 dll.
Is there any type of hack to have the application think it is located somewhere else temporarily so the dll would be found?
I'm also aware of the use of service(web, windows) to enable the 2.0 app calling the 4.0 app. Any other possibilities would be appreciated other than the three above.
You should be able to use the
<probing>
element in yourapp.config
to have the CLR look in sub folders while looking for assemblies. So if your 4.0 DLL is in the sub folderComDll
your app.config would look something like this:The private paths must be subfolders of your EXE, which should work in your case.