I have created an exe program based on ocx file and I used VB Package & Deployment wizard to install the exe file as a program on a non vb environment, the problem is I am getting this error when running the program
"RUN TIME ERROR '440' AUTOMATION ERROR.
What do you think is the problem?
Thanks
The 440 Automation error usually indicates that one (or more) COM object failed to load.
This might be an ActiveX exe, ocx, or maybe one of the external dependencies you included in your project.
Make sure all the external libraries you use are registered correctly on the system that's giving the error.
You can test this by registering the ActiveX (.ocx, .exe), and COM components (usually .dll) manually.
ATL/COM, ActiveX EXE, OCX, DLL
If the target assembly is a COM/ATL assembly, you can use regsvr32.exe (located in windows\system32 directory) for the ocx files and the COM- dlls. You can register an ActiveX-exe by running it with the option /regserver see: http://support.microsoft.com/kb/297279 and http://support.microsoft.com/kb/146219
.NET ComVisible
If the target assembly is a .net assembly which uses ComVisible, you can register it with regasm.exe, it is somewhere in the .NET framework directory. see: How to register a .NET assembly as COM?
Or else
You might want to use a tool like dependency walker to check which registration and dll's are missing from your system.You can download it from here, http://dependencywalker.com/ beware, run downloaded exe's at your own risk.
Related
In Visual Studio (C#), ticking 'Register for COM interop' updates the Windows environment such that my Visual Studio project, its dependent Visual Studio projects (in same solution) & dependent DLL files are all available for another COM-consuming application on the same machine. This COM-consuming application works with no issue.
If I want the same COM objects to be available to a consuming application on another machine, what must I do?
I assume I still build with the same flag set (so that the DLL files have COM content)? I assume I must register the COM DLL file (e.g. regasm) - Unfortunately this doesn't work - do I register every DLL file that I am constructing & every DLL file library they reference?
Please make no assumptions about my COM knowledge.
You don't quite provide enough information to answer with certainty, but there are enough hints to guess at what you are doing.
When your client app asks for the COM object, the .NET runtime is invoked and it locates the COM-exposing assembly DLL from the information stored by RegAsm (specifically by the /codebase parameter). But after that, it's all .NET assembly loading rules - including the loading of dependencies.
If your COM assembly has dependencies, the dependent assemblies must be locatable from the client process. It doesn't matter whether the dependencies are in the same folder as the COM DLL - the one loading those dependencies is the process, not your COM DLL. The .NET runtime uses a process called Fusion to decide where to look for .NET assemblies.
You have two practical choices:
Put the COM DLL, its dependencies and the client EXE all in the same folder. This works if there is only one client, and you control the client (so, don't do this if the client is IIS, for example). It's the simplest solution.
Give all the .NET components a strong name and deploy them to the GAC1. You still have to run RegAsm; but don't use the /codebase argument.
It is also possible to customize the Fusion rules by giving the client app a manifest with the proper entries, but that's too much of a hassle. The other options are more practical.
If this doesn't describe your problem, then I would use a combination of SysInternals' (now Microsoft's) Process Monitor and the .NET fusion log functionality to look into where the process is seeking the different DLLs.
1Technically you don't have to put the main COM DLL in the GAC, but it makes no sense to use /codebase for the COM DLL when you have to deal with GAC anyway. At that point you might as well put them all in the GAC
I'm creating a basic MSI installshield 2014 project. I've added a custom action which calls a public method present in a managed .Net assembly (MyCSharpAssembly.dll). Now my managed dll in turn calls a method present in an unamanged/native assembly (MyUnamanagedCPlusPlusAssembly.dll) written in C++. I used DllImport methodology to load the native assembly at run time.
I added the native dlls into support files ( [SUPPORTDIR]) based on the accepted answer of this thread. I also see those native assemblies getting copied in the temporary working directory of installshield when I run the MSI output. Still, it doesn't work? When installer runs I simply get following error in the logs-
Failed to load assembly. Dll not found.
This essentially means CLR/.net run-time is unable to see the native assembly dlls at run time. Does anyone have any idea on to specifically load native dll dependencies during installation process?
I have a COM DLL (MyWrapper), with a COM ATL Object (class) defined inside. This COM dll is basically to be an interface between my WPF .exe and native MFC DLLs.
Everything works perfectly fine until I put the COM DLL in my source control to check in the code. I put the Pre and post build events to copy the DLL to our desired location. when I compiled I got the error.
Unable to register the dll. Try enabling per user redirection
I enabled the option in linker. The DLL compiled and copied to the directory successfully. Then I tried to add the reference to the WPF project, it gave me the following error
A reference to MyWrapper.dll" could not be added. Please make sure that the file is accessible and that it is a valid assembly or COM component
When I remove the pre/post build events and then add the reference, everything works great. I loaded the DLL in Dependency walker it shows IESHIMS.dll is missing.
I have tried to register the DLL using regsvr32 but that returns an error:
The module 'MyWrapper.dll' was loaded but the call to DllRegisterserver failed with error code 0x80070715.
I have admin rights on my machine and am running Visual Studio as administrator.
In the postBuild events, I created a Proxy dll of the COM and added that dll in my WPF application. This solved my problem.
I have a Visual C# Project that is fairly basic (no more than 100 lines) but it includes some 3rd party DLL references. Running the project on the computer it was developed on has it run just fine.
In Microsoft Visual C# 2010 Express, I go to Project->Publish <project name> and it builds some files including a setup.exe installer.
When I move those files to another computer and run the setup.exe, it correctly installs the program.
But when I run the program, it simply closes out saying:
ProjectName.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
The command window also appears for a brief second with some errors, but it's hard to make out what it is saying. It looks something like:
Unhandled Exception: System.Runtime.InteropServices.COMException: Retrieving the COM class factory for the component with CLSID { ....... } failed due to the following error: .....
I'm unable to get the command window to stay, so I cannot get the full message. But I assume this is due to the other computer not having those 3rd party DLLS.
How can I have Visual C# 2010 package everything including DLLs so this error does not appear? Or if that may not be the actual issue, how can I stop the command window from instantly vanishing? (I do not know the full list of DLLs required)
Or if the DLL is a registered DLL under C:\Windows\system32, is the project never going to build that into the package? Is there a way to see what it depends on?
Visual Studio 2010 Express doesn't create fully functional installers, but only ClickOnce installers, and those also with limited functions. This kind of installer can't register COM DLLs.
What seems to be wrong in your case is that you are using a COM DLL which isn't registered on the target system. You could try to check that in your own program (like trying to create the class and catch any exceptions that are thrown by the CreateObject function), and call RegSvr32.exe /s in order to register it. Or you just do this when the program starts the first time, before you create any object from the DLL... haven't tried that, though.
You could also make sure that you register the DLL manually on the target system before you run your program.
Moreover, when .Net uses a COM DLL, it usually creates a compatibility assembly which wraps the COM DLL and makes it accessibly to .Net. In case the DLL you use is only this compatibility assembly, you might have to locate the COM DLL it depends on manually on your system and to include it explicitly in your project's files.
In order to debug, it should be enough to put try / catch blocks around CreateObject. If that doesn't help, try adding an eventhandler for the event that is raised when an exception isn't handled by the application (this might be different according to the kind of application you create).
I have an error that I suspect might be caused by different versions of the CRT being loaded on two computers running Windows 7. How do I determine which version of MSVCR90.dll in the winsxs folder is being loaded?
My program is a DLL being loaded by another EXE. It is compiled using Visual Studio 2008 SP1.
As Al Kepp answered, you can use Dependency Walker, "Depends.exe". For DLLs that are dynamically loaded, the best way is to profile the application as it loads your library.
In Dependency Walker open the EXE, not your DLL. Then click "Profile-->Start Profiling". If the application requires arguments you can provide them in the window that opens, otherwise just click "Ok" to launch the program. Once the program is open, use it in the normal way so that it loads your DLL. Now that your DLL is loaded, you should be able to browse the tree in Dependency Walker to see which versions of the CRT are being used.
If you can't see the version, ensure that the full paths are shown in the tree by clicking the "C:\" button.
You can also see which version of the CRT the application or library is requesting by checking the manifest, which is generally, but not always included in the DLL or EXE. in Visual Studio, click "File->Open->File..." and select the EXE or DLL. Open the RT_MANIFEST resource and you should see some XML which lists the CRT as a dependency and the version.
Most applications using these language libraries in DLL files use simply the latest version of those DLL in Windows directory. If you for some reason need some specific version, the easiest what you can do is probably to put those correct files to the same directory as your exe.
You can use Dependency Walker application to see which DLL files are loaded into your process on startup. You can download it from Microsoft site for free.