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.
Related
I did some edits to a class of a an activex dll project in VB6 IDE, made a newer dll by clicking on « make dll » a newer dll had been generated.
Copied the dll and tried to register it by calling regsvr32 in client server. the registration had been completed : i checked the registry keys and newer keys has been generate for my object.
When i start the website i have an error in the first class called ( which i didnt edit at all )
Actually, those dlls are installed as an application com+ so they can be called from classic asp pages. However, simply registering my new dll with regsvr32 does not make it work.
By the way, when i put back the older dll, everythings Ok
Any idea how to update this com object and why registering the dll does not work?
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 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.
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 a C# 4.0 application that is referencing a type library from a C++ application. This is used for some secure COM interop, a question I originally had asked here.
On my development machine this second application is installed so I can compile without any issues. If I attempt to compile on our automated build server, or any machine with Visual Studio installed but without this second program, I receive the following errors and compilation fails:
Text for google:
The type or namespace name could not be found (are you missing a using directive or an assembly reference?)
Cannot get the file path for type library "guid...." version 1.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
The referenced component 'SecurityAgentLib' could not be found
Picture for readability:
I'm not sure how to get around this other than by installing the application that registers the actual dll that implements these types, but I don't want to do that on our build server. The code that uses these types are wrapped in a class that is never instantiated unless prerequisite checks are run to verify the app is actually installed, so there is no chance of a runtime error. In fact I can run my app just fine on a machine without the second app installed - I just can't compile it there.
In visual studio the reference points to the .tlb file which is included in the solution directory, so the tlb file itself is present.
I can't imagine it should work this way, and I've searched around, but I'm apparently not searching for the right terms.
EDIT:
Running tlbimp.exe generates a dll but the type library should be sufficient for compilation, I thought at least. There is also an issue of broken references. I was reading this article Troubleshooting Broken References and it says that if the reference was to a COM component that is not installed than installing the component corrects the error, which is true.
Installing it on the build server really isn't an option. Opening visual studio and re-adding a reference if the path was broken doesn't work either.
I was able to use tlbimp to create a dll and used visual studio add a reference to that dll. That let me compile, but how would this work in an unattended build server?
EDIT
Okay I came up with two solutions that worked given my requirement of this all being unattended
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll in visual studio and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but if needed the build server could make modifications directly to this file to remove the tlb section and add a reference to the dll following a build of the second product.
Here are a couple options that each worked.
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but the build server could make modifications directly to this file to remove the tlb