Geek Answers Handbook

Do you want to use the COM dll file on deployed computers without registering DLL files

I will make it very simple, as it can get very confused very quickly. I have a COM-dll (made in VB6) that I would like to use in my C # application. Below are the steps I took and the results.

  • COM DLL created through Visual Basic 6
  • Added COM DLL to .Net application.
  • Get the file "interop.dllName.dll" generated by .NET in x86 / Debug
  • Added the interop file as a reference assembly to my exe file with CodeDom code.
  • The .exe file generated by CodeDom worked fine on my machine when the .exe file was in the same directory as the interop.dllname.dll file
  • The generated CodeDom.exe file did not work at all on the deployed machine, although the interop.dllname.dll file existed in the same directory as the .exe file.

Note:

  • The source COM .dll file is not registered on the deployed computer because the deployed computer does not recognize the COM-DLL as a valid dll file.

  • COM.dll was created in x86, and the deployed machine runs in x64 (does it matter)?

What is my goal: I would like to be able to generate the .exe file with the CodeDom code without depending on the interop.dllname.dll file. Is there a way to store these dll files in memory? In addition, I do not want my user to have to register the DLL files before they can use the generated .exe codedom file. Is there any way to do this?

I appreciate any help on this.

Thank you for your time,

Evan

+4
source share
3 answers

It sounds very similar to the fact that you have a direct 32/64 bit mismatch. Since your COM library is 32-bit, you need to:

  • Make sure that applications that consume this target are x86 COM DLLs.
  • Register the COM-DLL with the 32-bit version of regsvr32, which is located in the SysWow64 folder on the 64-bit machine.

I assume that you are trying to register with the 64-bit version of regsvr32 . If you make sure that everything related to registration and consumption is 32 bits, then you should be fine.

+3
source
  • A 64-bit process cannot load 32-bit DLLs. One way to mitigate this is to make sure that the .NET application is compiled only for the 32-bit version (called x86 in Visual Studio).
  • To remove the dependency on the dll interop, evaluate the option "Insert interaction types" in VS2010. I have not tested this myself, but I believe that it has been added for scripts like yours.
  • To register a free COM, I think the article can help as a starting point for you: http://msdn.microsoft.com/en-us/magazine/cc188708.aspx#S1
+2
source

The first problem, the interop.name.dll library, can be easily solved by decompilation. Just decompile the library and include the source code in your original library. You can use any decompilation tool, IlSpy must do this.

As for COM, there is a technology called "Registration free COM", it was introduced in Windows XP, more about this here http://msdn.microsoft.com/pl-pl/magazine/cc188708(en-us).aspx . Although it certainly works, I'm not sure if you have any problems due to x86-x64 mismatch.

+1
source

More articles:


All Articles