I am trying to run an addon in debug mode (x64) in Visual Studio for SAP B1 version 10.00.150. This addon worked well in version 9.3.
I have updated the .dll files for SAP bobs and boui with the correct version in the code. This is a Hana DB. I have made sure I have put in the correct connection string for debug.
I am running both SAP B1 client x64 and Visual Studio as administrator.
However, I get an error at this line:
// First initialize the Company object
Company = new SAPbobsCOM.Company();
Error:
System.TypeInitializationException
HResult=0x80131534
Message=The type initializer for 'SAP_DMS_Integration.Helpers.SboConnection' threw an exception.
Source=SAP_DMS_Integration
StackTrace:
at SAP_DMS_Integration.Helpers.SboConnection.get_SboApplication() in C:\Users\sconsult1\Desktop\CCL\DMS\SAP_DMS_Integration\SAP_DMS_Integration\Helpers\SboConnection.cs:line 17
at SAP_DMS_Integration.GUI..ctor() in C:\Users\sconsult1\Desktop\CCL\DMS\SAP_DMS_Integration\SAP_DMS_Integration\GUI.cs:line 33
at SAP_DMS_Integration.Program.Main() in C:\Users\sconsult1\Desktop\CCL\DMS\SAP_DMS_Integration\SAP_DMS_Integration\Program.cs:line 17
Inner Exception 1:
FileNotFoundException: Retrieving the COM class factory for component with CLSID {632F4591-AA62-4219-8FB6-22BCF5F60100} failed due to the following error: 8007007e The specified module could not be found. (Exception from HRESULT: 0x8007007E).
This is the SAP version running:
I have added the correct .dll files for the version in code:
How do I fix this error?
The error means the .net runtime can't find and instantiate the DI-API COM object. The issue is probably due to one of these:
DI-API is not installed
The bitness of the installed DI-API doesn't match the bitness of your Addon
You have a 9.x DI-API installed (different COM GUID)
The correct DI-API is often installed along with the v10 client, but I don't think it's a prerequisite. If you have DI-API installed it will usually show up on the Windows Add/Remove Software list. Make sure it's installed, and if it is try reinstalling it.
I would recommend you to always install both the 32 bit & 64 bit version of DI API on where you are going to run your project, and reference the SAP Business One SDK DLL in your project (less hassle as it will choose the correct DI API version (bit wise) depending on the environment.
Daz mentioned bitness, which is what I am talking about here, just spelling it out a bit more :P 100% of the times I'm struggling with the Retrieving the COM class factory for component it's based on me having the wrong DI API installed. Sometimes I was sure I wouldn't need the 32 bit but my projects could contain another DLL that forced the project to build as 32 bit, hence DI API 64 bit wouldn't be sufficient.
you have most likely set your project's bitness to Any-CPU, but your projects target was still set to Prefer32bit=true (as it was SAP9.3 projects)
this way the VisualStudio was trying (and failing) to find the 32bits version of DI API.
Once i have changed Project's PlatformTarget to x64 the Prefer32bits went to false and became greyed out.
(i just had this issue today and this was the solution)
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.
my scenario is the following (Win7, VS2010, .NET 4.0):
I have a .NET assembly from an external company compiled for "Any CPU" (verified with corflags.exe). This assembly loads a native dll also from the external company. This native dll exists in two versions - x86 and x64. I have both available.
When I create a console application, add the .NET assembly (while making sure one of the native DLLs can be found by the .NET assembly), create an instance of one of the classes from that .NET library and start the program everything is fine.
However when I follow the exact same steps within a WCF Service, I am getting a BadImageFormatException. Now the obvious thing is search for the error in the targeted platform (I tried "Any CPU", "x86", "x64") or trying to exchange the native DLL (I tried both x86 and x64), but that does not help. I tried all combinations btw...
Does anyone have an idea what the problem might be?
Lars
P.S.: I read BadImageFormatException encountered with WcfSvcHost and IIS WCF host and as the author states he solved a similar problem by corflagging WcfSvcHost.exe as 32BIT, but WcfSvcHost.exe is strong named so I can't resign it. Not sure how he got it to work...
You could drop the dependency on WcfSvcHost, and host/debug the service in a local IIS where you can explicitly set the AppPool to either 32 or 64 bit. That's what I'd do.
Hai,
i were working in Windows xp. last week I changed my OS to Windows 7.The project i have done in Vb.net(2008) . While running class not registered error comes. In another computer its works well. Why it comes.
Is the other computer Windows 7 too?
I have personally seen "Class not registered" error for COM/DCOM (unmanaged) applications or .NET applications that expose COM Classes.
Does any of the dlls/exes on which your project depends or any dlls/exe in your project itself expose COM classes? If so, then they are not registered properly.
You can try:
a. Registering all COM classes using regsvr32.
b. Register all .NET exposed COM classes using regasm /tlb /codebase
c. Try RunAs administrator for your application.
d. Turn on Fusion logging:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"ForceLog"=dword:00000001
e. Turn on DCOM Logging:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"EnableDCOM"="Y"
"ActivationFailureLoggingLevel"=dword:00000001
"CallFailureLoggingLevel"=dword:00000001
I have a third party COM dll that I'm trying to add to a vb.net (2008 express) project. I put the dll in C:\WINDOWS\system32\ and registered it with "regsvr32 vxncom.dll". When I go to projects > add reference and go to the COM tab it shows up in the list of available components/libraries. But, when I select the library and hit ok, visual studio complains: "A reference to 'vxncom 4.0 Library' could not be added. Could not register the ActiveX type library 'C:\WINDOWS\system32\vxncom.dll'."
The project I am doing this in is an example provided by the folks who distribute the dll. The component also fails to be added when I start a new (blank) vb.net project.
UPDATE 1:
I ran dependency walker on the dll in question and here's what I got in the error log:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
The module in question seems to be libeay32.dll, but it already exists in C:\WINDOWS\system32.
UPDATE 2:
I went to the openssl site and downloaded and used their installer to update the libeay32.dll. I ran dependency walker again on vxncom.dll, and there were no errors. Went back to visual studio and it still didn't want to add the reference. Exact same error as before.
Maybe the DLL VB is trying to register depends on another DLL that is not present. You can confirm this (or rule it out) by using the free Dependency Walker tool from http://www.dependencywalker.com/
RESPONSE TO UPDATE 1:
Sounds like there's a mismatch between the version of libeay32.dll that's installed on your system and the one that your component is expecting -- depends is saying that your component is looking for a function that isn't there. I would check the version number of libeay32 and then contact the vendor and ask them what versions they support.
Just a thought - you may get a more detailed error message if you create your own PIA using tlbimp.exe, rather than relying on the IDE to do it for you.
Assuming you haven't fixed it or have moved on to alternatives; and following on from jeffm's answer is libeay32.dll properly registered with the operating system? Re-installing / repairing usually fixes that type of problem (I see it a lot with MS Office and MapPoint where the COM objects occasionally unregister themselves for one reason or another.)