I am trying to register a DLL using WiX. Now I know and understand that I should use heat and get it to pull the registry information for me, but heat seems to fail with the following error message: heat.exe : warning HEAT5150 : Could not harvest data from a file that was expected to be a SelfReg DLL: C:\Users\seb\Desktop\Development\addin.dll. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpful to diagnose the failure: Unable to load file: C:\Users\seb\Desktop\Development\addin.dll, error: 193
I've looked around and found this post which explains a bit more in detail about registering DLLs but I would like to avoid the self registration route if possible. I also see mention of manually registering the DLLs further down below, but I'm not too well versed with the registry or COM objects that well to know where I could even get the CLSID, ProgId, and any other information that has been mentioned.
If anyone can point me in the right direction or explain to me what I need to do to run the DLL through heat it would be greatly appreciated.
I know this is old but I wanted to add an answer here - the reason this occurs is because the dll you are trying to register is 64 bit dll - and Heat.exe is 32 bit so it cannot load the dll in its address space. Anyway, just point to a 32 bit version of the dll to create the wxs file and you should not receive that error.
Is this an unmanaged / native DLL? Does Dependency Walker show any missing dependencies? Usually this means the DllRegisterFunction failed and Heat couldn't extract any data. Fix that problem and you should get good XML meta.
I was getting same problem with Wix heat.exe : warning HEAT5150 : Could not harvest data from a file that was expected to be a SelfReg DLL. The reason is dll was unable to find dependency to load. I think you must be having similar problems. I ran Process Monitor tool and applied filter to capture heat.exe event. I was able to find the root cause of the problem. Basically I had to put all dependency dll to same location where my main dll was. For your case addin.dll needs to point to the same location where your dependent dll's are.
The following blog about this warning helped me lot to figure out root cause.
http://marc.durdin.net/2009/12/case-of-hidden-exception.html?
Related
I've tried for many hours to find the solution for my problem and couln't find it even here.
So I have that application.exe that I am writing the Wix Toolset installer for it. Unfortunately I have no access to the source code but I hope I can do my task without it.
The problem is that it runs correctly with vc_redist.x64 installed on the end user's machine, but not without it.
What I've tried:
I was trying to run it without those runtimes and got into "couldn't find vcruntime140.dll error"
So I pasted it in the app's folder and tried to move on with dll's and the next error occured as shown in picture:
the application was unable to start correctly (0xc000007b). Click OK to close the application
I've read those runtimes after installation go into eg. "C://Windows/System32"
so I tried to go to that location and
dir > before.txt
and
dir > after.txt
after installing the vc++ runtime.
and copy pasted the files that occured only after the installation.
I tried to use gumpbin.exe from Visual Studio that gave given output:
found some dependencies
and the Dependency Walker gave me kind of similar output.
Dependency Walker output the same libs as direct ones, but also gave imo about hundreds of indirect ones. So I thought copy/pasting all of them is a really hard job without software to help.
I was also thinking about forcing vc_redist.x64.exe to extract files to folder given by me so I could use them for my purpose and the only parameter that looked fine was /layout but it only copied the whole .exe to another folder. Didn't extract it.
My questions is:
is there an easy way of obtaining the vc_redist.x64 libraries so I could author only the needed ones in my installer?
Any help will be appreciated. Thanks in advance!
Edit:
My goal is to secure newbie end users from being unable to run the application when they accidentally uninstall the VC runtime, therefore having vc_redist.exe as prerequisite in bootstrapper is unfortunetely not the case
I've been asked to install an old VB program on an XP computer, but when I do I get an error when I run the program saying that Component 'filename.ocx' or one of its dependencies is not correctly registered: a file is missing or invalid.
This is a custom file (I did not create it), I have tried regsvr32 and I get no error messages but no successfully registered messages either.
This program also runs on another computer which this ocx file is not registered but opens without error. So my question would be what could cause the file to not be recognized by regsvr32, and run on another client with the same os, but without error. Any ideas, or new paths to look into would be very helpful.
Also if you dislike something about this question, let me know what it is, so I can fix it in the future. Down voting a question gives me no insight on why this upsets the community, it just discourages me to want to help others in areas I do understand.
If you do get the error "Component 'filename.ocx' or one of its dependencies is not correctly registered: a file is missing or invalid" from a custom dll or ocx file, it may just need that file and its dependent files in the directory that your running the executable, as was the problem in my case.
After adding the file to the root directory, and not registering any files the program opened fine. Maybe this helps someone else.
A wrong version of a dll (MSVCR90d.dll instead of MSVCR90.dll) gets used for the delete operator, causing a crash. In the callstack, only the dll name is shown, not their path. How to see the path?
Edit: I'm building in Release mode, not in debug mode. So why does the debug dll get used? I have seen the same problem reported on many other websites, but could find no working solution.
Yesterday I found using Dependency Walker that the debug dll is getting picked up, so I renamed the dll, then the release version got picked up in the Dependency Walker, and also my program did not crash. I didn't change anything today, but the program has started crashing again. And when I see the dependency walker tree, it shows MSVCR90d.dll (the debug dll) with a question mark, saying it couldn't find it in the path. Why can't it pick up the release dll? Also I don't know from where the debug dll gets used by the runtime.
You can add them in your global PATH environment variable. Refer here
You can specify the dll manually by right clicking on the solution and selecting Add Reference, then browse to the particular dll.
You can add the path to the DLLs to the Executables files settings under Tools > Options > Projects and Solutions > VC++ Directories
For finding out the details of a dll, you might want to use DependencyWalker
However, in your case I think d is being appended to the name of dll, probably because you are creating a DEBUG build, and for that corresponding DEBUG versions of all dlls are loaded.
If you choose to create a RELEASE build, you would not have a d appended to MSVCR90.dll
You don't need to know Dll path, you need to understand why Debug version of delete operator is called. Maybe, _DEBUG constant is defined in Release configuration.
My Problem: I am using Matlab COM Automation Server to call and execute matlab .m files from a VB.Net plugin for a CAD program called Rhino 3D. The code works flawlessly when set up as a simple Windows Application in Visual Studio, but when I insert it (and make the requisite reference) into my .Net plugin and test it in the CAD program I get the following error:
"Could not load file or assembly 'Interop.MLApp, Version 1.0.0.0,
culture=neutral, PublicKeyToken=null' or one of its dependencies.
the system cannot find the file specified."
What I've Tried: I am baffled as to why this occurs, but I was able to contact the CAD program's technical support staff and they suggested that it has something to do with their DotNet SDK having trouble with references that are located far outside the CAD program directory. They didn't have any solutions so I tried playing around with copylocal and this made no difference. I tried using other COM libraries and the Open Office automation server works fine, although uses url's instead of requiring a reference. I also tested Excel, which does require a reference, and it returned the error: "retrieving the COM class factory for component with CLSID {...} failed due to the following error: 80040154." This may or may not be related to the issue with the Matlab COM reference, but I thought was worthwhile to share. Perhaps is there another way to reference Interop.MLApp?
I would appreciate any suggestions or thoughts on how I might make the Matlab Interop.MLApp reference work.
Best regards,
Ben
Try moving the assembly file(s) for MLApp into the bin directory. Based on everything I've read, this seems to be a glitch of some sort during the generation of the assembly binding where all the assemblies are merged together and their locations are assumed. I've included some links where I gleaned a bit of information about it.
http://blogs.msdn.com/isha/archive/2009/04/04/issues-with-wcf-service-when-the-asp-net-website-is-deployed-using-the-web-deployment-project-and-as-non-updatable-project.aspx
ttp://social.msdn.microsoft.com/Forums/en/netfxremoting/thread/30df57a8-2a57-4f9f-a120-30c24bc11681
ttp://social.msdn.microsoft.com/Forums/en/netfxremoting/thread/30df57a8-2a57-4f9f-a120-30c24bc11681
ttp://www.sitefinity.com/support/forums/sitefinity-3-x/bugs-issues/cannot-load-file-or-assembly-error.aspx
ttp://forums.asp.net/t/986130.aspx?PageIndex=8
ttp://stackoverflow.com/questions/408002/could-not-load-file-or-assembly-xxxx-or-one-of-its-dependencies-the-system-can
Is it possible to use early binding with LogParser.dll on VB6/VBA? When I try to set a reference to it, it just disappears with no error.
Oorang,
I ran Dependency Walker on the DLL. It says that dwmapi.dll is missing. Googling dwmapi.dll comes up with all sorts of matches, all related to problems with early binding of COM objects. dwmapi is a delay-loaded dll that exists on Vista machines.
I tried putting a copy of dwmapi.dll on my machine in the system32 directory. It won't register with regsvr32 (no surprise there, really), but it did eliminate the missing reference in Dependency Walker. However, Dependency Walker still returns an error message that says:
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Didn't really expect it to work anyway, did we?
dwmapi is not even listed in Microsoft's DLL database.
I saw you in the IIS forums. No answer yet.
Any chance you could late bind this thing?
Have you registered the DLL with COM?
Before using the Log Parser scriptable COM components on a computer, the "LogParser.dll" binary must be registered with the computer's COM infrastructure by executing the following command in the directory containing the "LogParser.dll" binary
C:\LogParser>regsvr32 LogParser.dll