Want to use COM dll file on deployed machines without registering dll files

I will make this very simple, as it can get quite confusing very quickly. I have a COM dll (made in VB6) tha开发者_开发技巧t I would like to be able to use through my C# application. Below are the steps I have taken, and the results.

1. Created COM dll through Visual Basic 6
2. Added COM dll to .Net application.
3. Retrieve the "interop.dllName.dll" file generated by .Net in x86/Debug
4. Added the interop file as a referenced assembly to my CodeDom generated exe file.
5. The CodeDom generated .exe file worked beautifully on my machine when the .exe file was in the same directory as the interop.dllname.dll file
6. The CodeDom generated .exe file did not work at all on the deployed machine even though the interop.dllname.dll file existed in the same directory as the .exe file.

Please note:

• The original COM .dll is not registered on the deployed machine because the deployed machine does not recognize the COM .dll as a valid dll file.

• The COM .dll was made in a x86 environment, while the deployed machine is running in a x64 environment (does this make any difference)?

What my goal is: I would like to be able to have the CodeDom generated .exe file run without the dependency on the interop.dllname.dll file. Is there any way to store these dll files in memory? Also, I do not want my user to have to register the dll files before they can use the CodeDom generated .exe file. Is there any way of going about doing this?

I appreciate any help on the matter.

Thank you for your time,

Evan

It sounds very much like you have a straightforward 32/64 bit mismatch. Since your COM DLL is 32 bit you need to:

1. Make sure that the applications that consume this COM DLL target x86.
2. Register the COM DLL with the 32 bit version of regsvr32 which resides in the SysWow64 folder on a 64 bit machine.

My guess is that you are attempting to register with the 64 bit version of regsvr32. If you make sure everything involved with the registration and consumption is 32 bit then you should be fine.

1. A 64bit process can't load 32bit dlls. One way to mitigate this is to make sure that the .NET application is compiled for 32bit only (called x86 in Visual Studio)
2. In order to remove the dependency on the interop dll evaluate the option 'Embed Interop Types' in VS2010. I haven't tested this myself but I do believe it's added for scenarios like yours.
3. For registration free COM I think article could help as a starting point for you: http://msdn.microsoft.com/en-us/magazine/cc188708.aspx#S1

First issue, the interop.name.dll library, could be easily resolved by decompilation. Just decompile the library and include the source code to your original library. You can use any decompilation tool, IlSpy should do it.

As for COM, there exists a technique called "Registration free COM", it's been introduced in Windows XP, more on this here http://msdn.microsoft.com/pl-pl/magazine/cc188708(en-us).aspx. While it surely works, I am not sure whether or not you'll encounter any issues because of the x86-x64 mismatch.