When I try to register a Visual FoxPro DLL via an administrator command prompt:
C:\Windows\SysWOW64>regsvr32 C:\_temp\my.dll
on machines that are not mine I get the following error:
The module "c:\_temp\my.DLL" was loaded but the call to
DllRegisterServer failed with error code 0x80004005.
For more information about this problem, search online using the error
code as a search term.
I am able to register it on mine. How do I get more info as to why it is failing?
Can I use my machine where it does register to back into why it doesn't register on other machines?
I've manually copied MSVCR70.dll into the %systemroot%\SysWOW64 directory on the machine that it won't register on.
I've reviewed the dependencies with https://github.com/lucasg/Dependencies and everything looks good.
I have typically found and associated 0x80004005 with permissions. Did you try to run the DOS prompt AS ADMINISTRATOR?
Also, VFP is ONLY a 32-bit application/dll, it was never 64-bit support, so you probably need the files in System32, not SysWow64.
Permissions might also need to be confirmed for those USING the dll. Ex: you install with admin permissions to drive
C:\SomePath\YourVFP.dll
Make sure the end-user has permissions to this path/file as well.
Aside from the above points... Do you have the VFP SOURCE code / project to build the DLL?
Based upon the comment from Tamar, I searched the registry for this DLL on a machine where I could register it and I found {CLSID}\Foxruntime\VFP7R.DLL.
I installed the VFP 7 Runtime from here (github.com/VFPX/VFPRuntimeInstallers) and I was able to register the DLL 😊
I have a general question. If I need to deploy an assembly as part of my product, which needs to be registered on a client machine and the tlb file created, people suggest to use WiX toolset's heat harvesting tool.
However, do I need to register (regasm) that assembly initially on my PC in order first to run the heat tool on that file and get all necessary data (registries) related to it and then when the final msi package will be ready including that data for the file when installing it will put all that back on client's machine? Or perhaps I don't need to register that assembly on my developer's machine, and I just run heat on the regular assembly file, but heat knows auto-magically and generates the necessary registry data for the file later to be installed on client's machine and be registered as regasm?
Can you confirm that the same idea and technique applies on when registering COM component using the regsvr32.exe? Again do I need to register the COM component on my developers machine first before including the heat's generated data related to that component into my installation package, or there is no need to register the component on my PC prior to run the heat on it?
do I need to register (regasm) that assembly initially on my PC
NO. I tested this. You don't need to run regasm if you checked "Register for COM Interop" setting in your .NET build settings, which will create TLB for you.
Otherwise, you could run REGASM /TLB to create the TLB.
but heat knows auto-magically
YES. You must run HEAT on the TLB and DLL.
Can you confirm that the same idea and technique applies on when registering COM component using the regsvr32.exe?
YES
Again do I need to register the COM component on my developers machine first
No. I didn't test this.
I got the following error while running the vb6 project in windows 7. I was search in google. I can't find the exact solution. Please help me to fix this issues.
The component CCrpDtp.ocx or one of its dependencies not correctly registered.a file is missing or invalid
The most obvious thing is to check to see if you have the ccrpdtp.ocx file installed and registered on your machine.
If you do not, go to the Common Controls Replacement Project site and download ccrpdtp6.zip.
The file contains the control and a dll dependency, both of which need to be installed somewhere on your machine. There's also a readme file which explains that you have to use regsvr32 to register the ocx.
Running an application from Visual Studio 2012 on 64-bit computers, displays the following error message:
Retrieving the COM class factory for component with CLSID {F2D4F4E5-EEA1-46FF-A83B-A270C92DAE4B} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
I am using Inventor packandgo dll library in visualstudio.
Anyone know what is the error?
My problem and the solution
I have a 32 bit third party dll which I have installed in 2008 R2 machine which is 64 bit.
I have a wcf service created in .net 4.5 framework which calls the 32 bit third party dll for process. Now I have build property set to target 'any' cpu and deployed it to the 64 bit machine.
When Ii tried to invoke the wcf service got error "80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"
Now Ii used ProcMon.exe to trace the com registry issue and identified that the process is looking for the registry entry at HKLM\CLSID and HKCR\CLSID where there is no entry.
Came to know that Microsoft will not register the 32 bit com components to the paths HKLM\CLSID, HKCR\CLSID in 64 bit machine rather it places the entry in HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID paths.
Now the conflict is 64 bit process trying to invoke 32 bit process in 64 bit machine which will look for the registry entry in HKLM\CLSID, HKCR\CLSID. The solution is we have to force the 64 bit process to look at the registry entry at HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID.
This can be achieved by configuring the wcf service project properties to target to 'X86' machine instead of 'Any'.
After deploying the 'X86' version to the 2008 R2 server got the issue "System.BadImageFormatException: Could not load file or assembly"
Solution to this badimageformatexception is setting the 'Enable32bitApplications' to 'True' in IIS Apppool properties for the right apppool.
The problem is that the DLL is registered on the 32 bit version of the windows registry, and the application is using the 64 bit version.
Solution: Go into the Project Properties, Compile tab and click "Advanced Compile Options...". Change "Target CPU" to x86, click OK, save and try again.
Source:
http://www.theogray.com/blog/2009/10/comexception-regdbeclassnotreg-on-64-bit-windows
Has worked for me with an VB 6 COM DLL invoked from a .Net 4 Winforms application
Somewhere in the code you are using, there is a call to the Win32 API, CoCreateInstance, to dynamically load a DLL and instantiate an object from it.
The mapping between the component ID and the DLL that is capable of instantiating that object is usually found in HEKY_CLASSES_ROOT\CLSID in the registry. To discuss this further would be to explain a lot about COM in Windows. But the error indicates that the COM guid is not present in the registry.
I don't much about what the PackAndGo DLL is (an Autodesk component), but I suspect you simply need to "install" that component or the software package it came with through the designated installer to have that DLL and appropriate COM registry keys on your computer you are trying to run your code on. (i.e. go run setup.exe for this product).
In other words, I think you need to install "Pack and Go" on this computer instead of just copying the DLL to the target machine.
Also, make sure you decide to build your code appropriate as 32-bit vs. 64-bit depending on the which build flavor (32 or 64 bit) of Pack And Go you install.
I had the same problem. I tried lot of ways but at last solution was simple.
Solution:
Open IIS, In Application Pools, right click on the .net framework that is being used.
Go to settings and change 'Enable 32-Bit Applications' to 'True'.
In 64 bit windows machines the COM components need to register itself in HKEY_CLASSES_ROOT\CLSID (64 bit component) OR HKEY_CLASSES_ROOT\Wow6432Node\CLSID (32 bit component) . If your application is a 32 bit application running on 64-bit machine the COM library would typically look for the GUID under Wow64 node and if your application is a 64 bit application, the COM library would try to load from HKEY_CLASSES_ROOT\CLSID. Make sure you are targeting the correct platform and ensure you have installed the correct version of library(32/64 bit).
Long solved I'm sure but this might help some other poor soul.
This error can ocurre if the DLL you are deploying in the install package is not the same as the DLL you are referencing (these will have different IDs)
Sounds obvious but can easily happen if you make a small change to the dll and have previously installed the app on your own machine which reregisters the dll.
I had run into the same problem. I added reference of Microsoft.Office.Interop.Excel COM component's dll but Office was not installed on my system it wont give compile time error. I moved my application to another system and ran it..it worked successfully.
So, I can say in my case it was the system environment which was causing this issue.
I had this problem and I solved it when I understood that it was looking for the Windows Registry specified in the brackets.
Since the error was happening only in one computer, what I had to do was export the registry from the computer that it was working and install it on the computer that was missing it.
I was getting the below error in my 32 bit application.
Error: Retrieving the COM class factory for component with CLSID
{4911BB26-11EE-4182-B66C-64DF2FA6502D} failed due to the following
error: 80040154 Class not registered (Exception from HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)).
And on setting the "Enable32bitApplications" to true in defaultapplicationpool in IIS worked for me.
For me, I had to install Microsoft Access Database Engine 2010 Redistributable and restart my computer.
This happened to me when I startup eclipse for a workspace and not other workspaces. In that workspace I had a *.ts file opened with "JS editor". Error occurred in spite of having correct file association in Preferences. Other *.ts file opened without error. To get around this, in "Open Resource" (ctrl-shift-r), I used the "Open With" button and selected "JS Editor", and the file opened without problem. After that eclipse knows the editor to use for that file. I solved the problem for one particular file type, but solution probably applies to all file types. Hope this helps someone. Thanks for reading
Check if the MS Office and MS Excel is installed on that server.
I'm trying to reference a COM dll in visual studio by using the Browse tab and selecting the DLL. I noticed that if the DLL is registered on the system with regsvr32 I can reference it, but if it's not registered I receive an error selecting the dll file "A reference to 'file.DLL' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
We would like to keep the DLL not registered, so that we have less configuration needed on other development machines and on the development environments.
Is it too much to ask?
Thanks!
you need to register dll. you can set registration in your setup project or create a batch file for all these type of processes.
Note: Don't forget to unregister dll on uninstallation.
You'll need to register the dll because otherwise it would not be able to find the type library.
Adding the dll afterwards as a reference to you project will create the interop.XXXXmethod.dll assembly.
You need to have the COM server registered, period. You could take some measures to automate the process though and to unregister the COM server when it is not needed.
The same applies to daily builds. If you build a COM server and a .NET based client during the build you have to register the server prior to building the client. And you better unregister it as soon as the client is built. Adding these steps to the build sequence is not a problem at all.
You might be able to use Registration Free Com