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
Related
I have a vb6 project, and when i tried to run the source code I got an error which points to the CMWImpt.dll.
I tried to put the dll in the System32, sysWow64, and project folder, and registered it. But this is the error:
CMWImpt.dll was loaded, but the DllRegisterServer entry point was not was not found. This file cannot be registered'
anyone who encountered this before?
thanks
What's the error message?
Not all dlls are registerable. Only COM dlls have registration. And they are usually but not always in the dll (sometimes in another dll).
Error messages that mention dll names are not COM errors mostly. COM errors are of the type "Cannot create activex object", unless correctly registered and the file deleted.
So your file is either corrupted or not a COM dll.
The WinAPI uses dynamic linking. DLL stands for Dynamic Link Library, COM dlls have 4 or so standard dynamic functions to controll COM like DLLRegisterServer.
So you need to provide more detailed info on the problem.
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?
I am using heat to harvest the COM dll and tlb files (let's call them MyLib.*, developed in VB.NET) to do the COM registration. Everything was working fine, when I install MyLib.dll and MyLib.tlb into my application's installation folder, i.e., INSTALLDIR. However, since we want to allow different versions of our SW to be installed on the same machine, and if they are using the same version of COM component, only one copy of the dll (I think each version of our SW should have its own tlb, please correct me if I am wrong) should be installed, we now want to install MyLib.dll into another folder, specifically PROGRAM_FILES\Common Files\SHARED_FOLDER_NAME, so now if one version of our SW is uninstalled, the MyLib.dll will not be removed and can still be used by other versions.
But here comes the problem: my COM registration is just simply not working any more after I install this dll into this another folder, and it keeps saying that can't find file specified when I am calling the COM function which indicates registration failure. In the WIX installer project, everything is the same except this folder for MyLib.dll.
Here is the registry structure after installation:
Firstly I have HKCR\CLSID{MYCLSIDs}, each of them represents one of my COM class. in the sub-key named "InprocServer32", I have Assembly, Class, CodeBase, RuntimeVersion, threadingModel. And the CodeBase is either common file folder (not working) or MyApp's installation folder(working), which is the different locations I put the dll. I thought there would be another sub-key TypeLib under {MYCLSIDs}, since Access only sees the TypeLib and I think there should be some link from the TypeLib to the actual dll, however, at both cases this sub-key is missing but in the second case it is still working. Is there a problem of it?
Secondly I have HKLM\Software\Classes\CLSID{MYCLSIDs}, these keys are of course the same structure as described above.
Thirdly, the HKCR{MYPROGIDs}, these are just ProgIDs of my classes
Fourthly, HKCR\Typelib{LibID}, which includes the information from tlb file, and this ID is from the Assembly GUID of COM component project.
Finally, the HKEY_CLASSES_ROOT\Interface{InterfaceID}, there is sub-keys named ProxyStubClsid32 with value {00020424-0000-0000-C000-000000000046}, and the one named TypeLib and the value is my LibID.
As I mentioned, the only difference is the CodeBase, which stores where MyLib.dll is located. In order to verify that, I did two tests: after I install MyLib.dll into the shared folder, the COM calling fails. But if I replace all the CodeBase values for SHARED_FOLDER\MyLib.dll to INSTALLDIR\MyLib.dll, and copy MyLib.dll into INSTALLDIR, it actually works. Vise versa, after I install MyLib.dll into INSTALLDIR(in which case COM is working), I change the CodeBase values from INSTALLDIR\MyLib.dll to SHARED_FOLDER\MyLib.dll, and make a copy to SHARED_FOLDER, this time it fails. So it seems that it is exactly the installation location's problem, which is the opposite to my understanding of COM. And I don't think there is a permission issue for the SHARED_FOLDER(I could be wrong) since it is in a folder that my installer creates.
Please help, thanks!
It turned out that MyLib.dll is using some other libraries, which are still installed in the MyApp installation folder. And so in that case that MyLib.dll is installed in the shared folder, it tries to find those libraries in the same libraries, which of course fails. When I install those libraries in the shared folder too, it is working.
BTW I found fulogvw.exe very helpful when tracking down the assembly loading problem. For example in my case in the failed log it says can't load file xxx.dll in SHARED_FOLDER, the xxx.dll is some library that MyLib.dll is using, and I had no idea that MyLib.dll needs it until I see the log.
I know that some dll files have to be registered with the regsvr32 command. I tried that on a dll files I got and got an error message saying that "the entry-point DLLRegisterServer was not found." I heard that to use theis dll file you have to use "ctypes." So what are you supposed to do with it?
Some DLLs contain COM interfaces. These can be registered, and provide hooks to do so. Others are just normal DLLs, and have entry points with names and/or ordinals. They must be linked appropriately by the script/executable.
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