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 have created a COM dll in .Net and build it under Any CPU. I am using that COM dll in Vcpp code but getting Microsoft C++ exception: _com_error at memory location error when creating the pointer reference to COM class. The VCPP code works perfectly fine if the Build configuration is Win32 but if i change the configuration to X64 mode then teh application crashes.
Please Help
Since you're using a so-called in process DLL, you have to use the 64 bits version of that DLL in your program.
This question discusses it. It seems that you have to use the 64 bit regasm tool to register your .NET DLL.
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 have an application that we wrote here at work that uses the SharpSVN wrapper for SVN. It has served us well of the past few years. However, we have started bringing in 64-bit systems and our application cannot seem to access the SharpSVN dll on these systems.
I have downloaded the 64-bit version of the SharpSVN dll and I am wondering what to do next. I cannot stop my 32-bit users from using the application, so I need to be able to compile for both platforms. Luckily, with this application, we split different layers of the ntier stack into separate projects within the solution so my business layer that utilizes the SharpSVN dll is on its own.
How would I go about compiling both a 32-bit and 64-bit version of my application without having to maintain two copies of the project?
Build your tool using the x86 platform (as opposed to Any CPU), and it will be loaded as x86 code even on 64-bit systems.
Or you can do something like
class SharpSvn64 {
[DllImport("sharpsvn64.dll")] extern public static void DoSomething();
}
class SharpSvn32 {
[DllImport("sharpsvn32.dll")] extern public static void DoSomething();
}
class SharpSvn {
static readonly bool Is64 = (IntPtr.Size == 8);
void DoSomething() {
if (Is64)
SharpSvn64.DoSomething();
else
SharpSvn32.DoSomething();
}
}
Edit: Since SharpSVN is managed, PInvoke wouldn't be the answer, so building x86 executables are probably the way. Or, if the interface is identical, you MAY get away with subscribing to the AddDomain.AssemblyResolve event and choose which assembly you want in that. I don't know if this is a good idea, though.
From the description, it sounds like your vb.net application is built with the Any CPU option, which means it would run as a 64-bit application on a 64-bit machine. In that case, it would not load the 32-bit DLL.
Rather than try to use both a 32-bit and 64-bit version, you should be able to just change it to run as 32-bit. Simpler deployment. Under the project properties build tab, choose x86.
I thought that latest Matlab does this automatically. I have tested the following exe on a clean Win XP VM:
namespace DotNetTest
{
using System.Windows.Forms;
class Program
{
static void Main(string[] args)
{
MessageBox.Show("Howdy!");
}
}
}
When I run it on a computer which has all these installed, it does show the message box and a window. When I run it on a clean VM, I get this error:
Title: DotNetTest.exe - Application Error
Icon: Error
Buttons: {OK}
Message Body: The application failed to initialize properly (0xc0000135). Click on OK to terminate the application.
I would expect better from MSFT geniuses. Why cannot every .Net exe contain a tiny bit of overhead and have the very first bytes of it do the work of detecting if .Net is installed and presenting a better message.
Is there some sort of setting that I can flip to fix this? All of the settings were default ones provided by VS2010 when I created a new project.
Thank you.
This is what you use an installer for. In .net this is simple, you just "publish" your project and you get an installer that makes shure that .net is installed and such. The application itself should never have to worry about that.
As Alexandr says, you should really use the installer for this. If that's not possible, you'd have to write an unmanaged exe to run first and then either start the .net exe or tell the user to download the framework depending on if it's already installed.