So I'm working in Clarion 6 and the problem is when I make an application and try to make and run it says it's missing some dll's. Couse Clarion 6 doesn't support 64 bit system's im working in a virtual machine(Windows xp) run by Oracle VM virtual box. I also noticed that when I build the application and go to the folder of the application I can put the missing dll's from the Clarion 6 installation folder and then run it normaly. But still it isn't the way the application is meant to be started.
Clarion6 relies on the path to point to the location of dependant DLLs during development.
Usually, as a minimum, you would expect to see this in the PATH environment variable:
c:\clarion6\bin;c:\clarion6\3rdparty\bin;
Of course when you distribute your application you will need to determine which DLLs are needed and ship then with your application.
So I found a solution to this problem. If you are using a win xp virtual machine to run your Clarion 6 you need to copy all dll's from the bin folder from clarion to your windows folder
On a Windows 7 x64 I have have written an application which also includes a .dll which is installed to the GAC. This has been working without error for about 3 years. I recently made a new version of my Application but did not change the version of the .dll. The application starts at boot time and now I get a message from Windows...
Caution ... You are attempting to open a file of type "Application Extension" .dll
And then it wants you to choose a program to run it with.
I uninstalled this version and installed my previous version and I do not get the error.
I have no idea where the problem is so my tags are an attempt to get the ball rolling. Wix is my installer program which might have something to do with it.
How is my Application started at boot time
There is a registry entry in \Software\Microsoft\Windows\CurrentVersion\Run which has a path to the Application's .exe file. This Applicaion has the dll as a reference.
So if you remove it from autostart and start it after the pc is fully up, does the same message appear ? If that worked, a workaround would be registering your app as a service and set its startup to delayed.
When i googled your error some malware- threads came up. If you straight up load your dll and its unsigned e.g. via rundll32.exe that might cause an issue - but i dont entirely know how your autostart-entrypoint looks like.
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 a namespace like this in one of my aspx pages (.NET 1.1)
<%# Register TagPrefix="jwg" Namespace="Janus.Web.GridEX" Assembly="Janus.Web.GridEX" %>
This code used to run alright in .Net 1.1 on a 32 bit system but recently we are porting it to 64 bit system (only the run time not the development environment). It has already been ported successfully on one 64 bit system - however that was done like months ago and I have now completely forgotten what all settings were done at that time (and unfortunately I did not take any notes at the time).
Everything runs fine except for few pages where I use the above mentioned namespace registration tag. It is throwing me a script error error at run time from browser saying that An error has occurred in the script on this page. Error: 'GridEx' is undefined. Do you want to continue running scripts on this page? The DLL in the bin is same as it is in on the another 64 bit working box. All other setttings on IIS seems to be working fine since I was able to set .NET 1.1 app pool on it and run the entire application.
Thanks.
In the Visual Studio I removed all the references and created them once again (choosing the path to bin directory of the project) and this resolved this issue... What was probably happening that even though in properties of the references it was showing the path to bin, but somehow the whole thing needed to be refreshed to reflect it into the compiled project file. Its Visual Studio 2003.
Thanks guys.
We have a project management application written in VB.net. When running this application from a 32-bit machine or from within the Visual Studio IDE on a 64-bit machine, it looks for the correct configuration file (i.e. MyApp.exe.config). However, when running this app from outside the IDE on a 64-bit machine, it looks for MyApp.config and fails to find it.
Obviously I can copy the correct config to the badly named config, but we're at a loss as to why this behavior is occurring in the first place.
This is a windows application written in the 2.0 framework. No web.config file is associated (as I have found some references to a similar issue with web.config files that didn't apply).
Any guidance or suggestions is greatly appreciated.
Edit: I also should note that this is the only application this is occurring on. If I create a new vb.net application using the same libraries we use for config management, it works fine. Also, of some possible relevance, the projects are being built targeting the x86 CPU.
What I'd do is on 64 bit at install time I'd do CreateHardLink("MyApp.exe.config", "MyApp.config", NULL)
CreateHardLink is P/Invokable.