I've got a new system. I am trying to connect to and run the system through a 64-bit Windows 7 PC. The company sent me a Visual Basic project for that. It uses .NET framework 4 and Windows Form Applications. The target CPU is x86.
In the References tab, next to three of the COM references there are "The system cannot find the reference specified" statements. When built, the project gives the namespace errors and warnings because of these objects. The other references work fine. I've then seen those .dll files in the debug folder. I think they are generated by the company before sending me. They also exist in the bin\debug folder.
I've removed the three from the references list in the project and tried the following separately:
1) In the project, refer to the .dll files that exist in the debug folder. (Seems a fake way, but removes all the errors when the project is built. When debug, it gives the "Retrieving the COM class factory for component with CLSID ... failed due to the following error: 80040154" error.)
2) Copy the .dll files in the debug folder to C:\Windows\SysWOW64 folder, then register through regsvr32 "name.dll" in the console as admin. This way, I get the ".dll was loaded, but the DllRegisterServer entry point was not found" error. (In the regedit window, the registry editor cannot find the ID's of those references that are seen in the project properties in VB.)
3) Do the item (2), but with the C:\Windows\System32 folder instead of SysWOW64. The same error when registering.
4) Changed the solution platform to x86 and tried the items 1,2, and 3. Still the same errors.
Do I have to register these dll files? And, am I supposed to register exactly these dll files that exist in the debug folder? Or are they supposed to be generated after build by referring to some 'missing' type libraries in the references tab? I don't have these type libraries, though.
All suggestions are welcome ASAP. Thanks in advance.
You have three Interop dlls for your project, correct? These dlls just allow you to use a COM dll without having to talk directly to the COM dlls yourself.
Referencing the dlls in the bin/Debug directory should be fine, since those are probably the correct dlls that the project was built with. However, you will want to move them to another folder before continuing.
What you need to get from the company that sent you the project is the original COM dlls and their dependencies, if any. Usually an interop dll is called Microsoft.Phone.Interop.dll where it is performing interop with Microsoft.Phone.dll. Microsoft.Phone.dll needs to be registered on your computer using regsvr32 and then you just need a reference to the interop dll.
Related
I am working with SDL2 and its add-on libraries SDL2_image and SDL2_ttf, using Visual Studio 2017. The libraries, and the .dll files that come with them, are in another folder (C:\SDL2.0\lib\x86), which is in the system path.
When I run, it fails, with this error message:
The procedure entry point InterlockedCompareExchange#12 could not be located in the dynamic link library C:\SDL2.0\lib\x86\SDL2.ttf.dll.
I can fix this by putting libfreetype-6.dll, which comes with SDL2_ttf, in the same folder as the .vcxproj file; or in the Debug folder. I can also fix it by putting the .dll into c:\windows\SysWOW64. But I want to distribute my code, and I don't want to put that file in each folder or require users to have admin access (to access c:\windows\SysWOW64); I want Windows to find it in the PATH, as it does with the other .dll files it's using here.
A few things I tried as I looked around the web for solution (to no effect):
Recompiling libfreetype-6.dll
Downloading the latest versions of all associated libraries
Rearranging the .lib files in Project Properties, Linker, Input, Additional Dependencies. Admittedly I may not have tried all possible arrangements as there are several dependencies
regsvr32 libfreetype-6.dll. This led to a different error message:
The module "libfreetype-6.dll" may not be compatible with the version of Windows that you're running. Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
I saw here that maybe I should use the version of regsvr32 in the system32 folder; when I do that, I get
The module "libfreetype-6.dll" was loaded but the entry-point DllRegisterServer was not found. Make sure that "libfreetype-6.dll" is a valid DLL or OCX file and then try again.
So: is there a way to get the program to find libfreetype-6.dll in another folder in the PATH, and eliminate the error message about the procedure entry point?
The program I'm testing on now is from the TrueType tutorial from the LazyFoo website (source).
We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...
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.
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.
I am trying to set up communication between Centura and a COM .dll. (Downloaded from http://download.resip.fr for a database import)
Centura requires a .tlb file to be able to communicate to this component. Normally I would use regasm /tlb to generate the .tlb but seeing as it is a COM .dll this is not possible.
I found that I could use tlbexp for .NET dll's: http://msdn.microsoft.com/en-us/library/hfzzah2c(v=vs.80).aspx
I tried this out, knowing it would probably fail (as I have COM .dll). I received this error:
TlbExp : error TX0000 : Could not load file or assembly 'file:///C:\Windows\system32\ResipBcb.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
Using Dependency Walker I noticed two .dll's missing. I found ieshims.dll online but I can't find the wer.dll. See this question.
I don't know if the tlbexp failure has anything to do with this file that is missing?
To sum up, my question is:
How do I get a .tlb from this .dll? I can't seem to find any way to extract the .tlb out of this COM .dll.
Best regards
Clint Cambier
What you are trying to do only works for .NET assemblies, not native COM servers. The type library for them is almost always embedded inside the DLL. In Visual Studio, use File + Open + File and select the DLL. Open the "TYPELIB" node, right-click the resource (usually 1), Export. Save it to, say, a project directory, use the .tlb filename extension.
TblExp and regasm are only valid on .NET assemblies, what you have is most likely a standard non .NET COM DLL. So neither of those two commands are valid on this DLL.
Standard COM objects are registered using regsvr32. Try running that against your DLL and see if it registers correctly. If it does you should see it listed in Centura's ActiveX explorer.