I've copied my dlls into both C:\windows\System32 and C:\windows\SysWoW64, and have executed regsvr32.exe into both of them, and have ended up with an error message telling me that name.dll may be incompatible and that I should try registering under the other folder.
Side note: I am running cmd as an administrator. I have Windows 7, 64-bit OS.
Edit: Also, I have confirmed that the dlls are 32-bit.
Is your DLL a COM DLL
The Regsvr32 Tool (regsvr32.exe) is used to register or un–register a COM DLL.
Regsvr32
Related
Is it OK for a COM DLL to be compiled as AnyCPU and work with both 32 bit and 64 bit applications?
Yesterday I started writing a C# COM DLL so that my MFC project could use the DLL. The DLL itself is for using the GMail API.
Initially I was compiling the DLL as either x86 or x64 and both of my executables were running fine.
Then I decided to change the DLL to compile as AnyCPU and now when my program runs it says Class not registered.
Does the DLL have to be compiled for each Bit edition then?
No, you can keep the .DLL compiled as "Any CPU" (in fact I certainly recommend it as long as you can), but you must register it in each version of the registry, so for example using regasm:
64-bit:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
32-bit:
c:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
I'm building a MSI that targets both 64 and 32 bit platforms, it contains a dll that is only being registered on 64 os. I'm using a custom action to register and unregister the dll :
when uninstalling the software and if the dll was manually unregistered, Uninstallation fails because the regsvr32 /u fails.
regsvr32 /u /s [InstallPath]filename.dll
how to check whether the dll is registered before launching the custom action.
You shouldn't be building one MSI package for both architectures:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
and you shouldn't be running regsvr32. Most installer tools have mechanisms to extract registration info into registry entries so that no code is required to run at install time. Tools that don't do that will still let you add your Dll to the MSI file's SelfReg table, and both these alternatives are better than running regsvr32.
Note that if you are in a 32-bit install, some (if not all) attempts to access the 64-bit folders are going to be redirected to the 32-bit equivalents, another reason for not using regsvr32 and creating separate packages.
I created an installer for my AnyCPU DLLs. I've marked my assemblies with teh Assembly=.net directive in my project as well. The installer seems to be able to register the COM servers successfully on my XP 32bit machine, but fails to do so in my Windows7 Machine. I did run the installer in admin mode. Also I looked up the Win764 registry and found those CLSIDs in the reigstry. So looks like the MSI did put some entries in the registry but somehow they are not being recognized as valid COM Server entries (OLE Viewer also didnt enumerate my server).
Any idea why this would happen? Any extra config do I need to add to my project?
thanks
Apparently you need to compile your msi as a 64-bit native binary to have the dlls registered in 64 bit mode.
I am writing a C# program that interface with COM object through COM interop.
I have a third-party program that register itself as the COM server when I execute the Application. This works fine in 32-bit Windows Vista and I can interface with the interop just fine. (The reference show up in "COM" tab from Visual Studio when you click "Add Reference")
However, the reference does not show up in "COM" tab on my 64-bit Windows 7 machine after I execute the application. Any thoughts, why would this happen? I actually tried using regsvr32.exe to register the application manually but it didn't work either (error message saying "entry-point DllRegisterServer was not found)
You are not going to be able to use it as long as it doesn't show up in the COM tab. The regsvr32.exe utility is for DLLs, this however sounds like an EXE. If it is a DLL then it needs to be registered with the 32-bit version of regsvr32.exe, the one in c:\windows\syswow64. If it is an EXE then the normal way to get it to register itself is by running it with the /regserver command line option.
Mumble.exe /RegServer
Additionally, if this is a DLL or an EXE for which you don't have a 64-bit proxy/stub then you'll have to force your app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86.
If all else fails, you really do need support from the vendor of this program. Surely they'll have an update available that is verified to work properly on 64-bit operating systems. If they are no longer around, running this in a virtual machine is always a possibility.
If it is a managed dll then you might try using RegAsm
REGASM AssemblyName.dll /tlb:AssemblyName.tlb
You may find this helpful as I needed to recompiled and build 64 bit proxy stub for the COM server from C++ myself and it kept failing when trying to register the server using /regserver. Here is and thread from miscrosoft that helped me resolved this issue. Basically you need to use this instead /RegServerPerUser, but go through the thread if you get into this situation after the answers from above.
http://social.msdn.microsoft.com/Forums/en/vcprerelease/thread/11f01ceb-52a4-438f-b7ef-727ce7a3e191
I am building a C# ActiveX DLL... do I use REGASM or REGSVR32 to register it?
How do I register the 64-bit interface vs the 32-bit interface?
You need to use regasm.exe to register both the 32 bit and 64 bit interfaces I believe you need to run each of the regasm.exe's in:
C:\Windows\Microsoft.NET\Framework\v2.0.50727
and
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
So... in your case you need to run the regasm.exe in the Framework64\v2.0.50727 folder.
Here's an example we use to register a COM interop DLL for one of our legacy ASP apps:
regasm.exe Hosting.DeviceManager.Power.dll /register /codebase /tlb
If the DLL is build in format of "Any CPU", no matter if you choose regasm in
C:\Windows\Microsoft.NET\Framework\v2.0.50727
or
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
DLL would be registered as 32-bit.