How to call functions of a COM DLL (In VC++) from a VC++ .EXE application? - com

I have a COM DLL (say, xyz.dll) coded in VC++. I want to create a calling EXE application (calling.exe) which will call the functions of the COM DLL (xyz.dll).
I followed the steps in the link http://www.codeproject.com/kb/DLL/XDllPt1.aspx.
But I am not able to connect the DLL and EXE and hence not able to call the functions of the COM DLL. I am totally new to COM and VC++ programming. Can anyone kindly help me with.
I am using Visual Studio 2005.
These are the exact steps I followed--------
STEP 1: Created a solution having the DLL project (xyz.dll) project and a caller application Project (calling.exe) of template MFC Application (Dialog based). Made this calling.exe as the startup project..
STEP 2: Went to the properties by right clicking on the calling.exe Project in solution explorer. Configuration properties --> C/C++ --> General--> Additional Include Directives and added the path to the DLL Project..
Step 3: Again Right Click on the calling.exe application Project went to Properties--> Configuration properties --> Linker --> Input --> Additional Dependencies and added the path to the .Lib file for the built DLL Project.
STEP 4: Right click on calling.exe application Project, Properties --> Common Properties --> References --> Added reference to the DLL.
STEP 5: Copied the xyz.dll file to the application project directory.
STEP 6: My DLL has many header files and its corresponding source files. So, Added all the header files present in the DLL Project to my calling.exe application program. Within the OnInitDialog() function present in one of the .CPP program of the calling.exe application, I called the functions of DLL.
Just the statements
Cx objname;
objname.func();
Here Cx is the name of the class in the DLL.
I did not do any changes with the configuration settings of the EXISTING DLL project because it is The DLL which is already prepared by an expert and I am writing just the calling applaction to call the functions present in this DLL.
THANKS IN ADVANCE.

The instructions you've followed are for calling functions in an ordinary DLL, not a COM DLL. To access a COM DLL you need to go through COM.
You don't link to the DLL's lib file or include any headers, and you don't need to move the DLL.
First, make sure the DLL is registered by running regsvr32 on it.
regsvr32 "c:\..\..\xyz.dll" ; insert the correct path
Then add an #import directive to your project's stdafx.h, containing the path to the DLL.
#import "c:\..\..\xyz.dll" // insert the correct path
Right click stdafx.cpp in the file view and choose compile.
This will generate the wrapper "smart pointer" classes you need to access your DLL.
The smart pointer classes have the same names as the interfaces in your DLL, but with "Ptr" on the end.
Look at the file with a .tlh extension and the same name as your DLL in your Debug directory. It begins with a C++ namespace declaration.
This is the namespace in which the objects you are going to create from the DLL reside.
Say the namespace is XYZ and you want to instantiate a Cx object, which exposes the Ix interface.
You would do:
try {
XYZ::IxPtr obj;
obj.CreateInstance(__uuidof(XYZ::Cx));
obj->func();
} catch (_com_error e) {
printf("Error: %S\n", e.Description());
printf("Error: %S\n", e.ErrorMessage());
}
You can then continue to use it just like an ordinary pointer.
You don't delete it when you have finished with it though, it will be destroyed automatically when it goes out of scope.

Related

Dynamically linked DLL is loaded immediately after starting the application

I've dynamically linked libhunspell.dll (HunSpell) to my application. It works, but there is a dumb problem which I don't know why it happens.
Even before I use LoadLibrary("path\\to\\libhunspell.dll"); to load it and use it, on the start of the application it attempts to load the library by itself. If I place the libhunspell.dll into the path where my main executable resides, it can load it, otherwise it reports an error, immediately after starting the application - This application has failed to start because LIBHUNSPELL.DLL was not found. Re-installing the application may fix this problem. and the application doesn't start.
I would understand if the LoadLibrary would use invalid path but this happens as soon as the executable runs, even before the first statement in WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int) executes (I've tried to place a breakpoint and it doesn't even reach it, so this happens before).
So, as a result, I must place libhunspell.dll in the same folder as my application executable, and not in the path I want.
This is probably easy to fix although I don't what to look for.
So the question is - how do I avoid it loading it immediately and have it wait until I use LoadLibrary call?
Here is how I linked if it can help:
1) compiled libhunspell.dll in Visual Studio 2015 (I used /MT option to link it statically so it doesn't have VC++ Redistributable as a dependency).
2) created import library (libhunspell.lib) using implib.exe -a -c -f libhunspell.lib libhunspell.dll
3) linked that to the source .cpp unit which is using it using #pragma comment(lib, "libhunspell.lib") (it is RAD Studio 2010 so the .lib is required unlike newer versions).
4) later in the same .cpp used LoadLibrary to load this library and used it.
By linking in the import stubs (libhunspell.lib) the OS will load the DLL for you as it is now a static dependency.
One approach would be specify the library as a delayload dependency: /DELAYLOAD:libhunspell.lib via the linker options. You can then call LoadLibrary on the DLL.
The only other option is to stop including the .lib in the linker step, making it truly a dynamic dependency.
I assume you did Add to project a *.lib file for your DLL. That is a kind of "static" linkage done in the App initialization (prior to your forms are created). So it has two disadvantages.
You DLL must be in the same path as the Apps EXE file
Sometimes DLL file name is locked (can not be changed)
The advantage is that you do not need to do any coding for the DLL loading as the VCL do it for you ... so your app should not contain the LoadLibrary,GetProcAddress calls you just include the *.h file with propper import declarations ...
For dynamic linkage you need to remove the *.lib from your project and use WinAPI LoadLibrary + GetProcAddress for loading your DLL as josh poley suggested. Here an example:
Builder C++ calling VC++ class
Beware there was/(is?) a bug in the GetProcAddress preventing from loading all the functions from your DLL in some cases. Especially if the DLL has old legacy mangling of names the count of functions is high and the DLL was created on compiler incompatible with the mangling in question.

Cannot find the reference specified-Visual Basic 2013

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.

Reference VB.NET DLL in Kofax Document Validation Script

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...

How to create a Silverlight class library that is downloaded once, like an assembly

I have a website solution that contains three different Silverlight 4 projects, and they all make use of the same Silverlight class library.
I have done this by creating a class library project within the solution, and referencing it from the other Silverlight projects.
BUT the class library is included in every one of the XAPs. The user could end up downloading the same class library multiple times.
How do I canvert the class library into a XAP that can be downloaded once, in the same way that an assembly is?
(And why isn't there a Silverlight Assembly project type in Visual Studio?)
You should use Assembly Caching - it's a way to leave dependent assemblies out of your xap file. Instead you need to deploy them with your xap file by placing them in a seperate zip file in the same folder.
In the properties window of your Silverlight application you can choose to enable Assembly Library Caching. That will automaticly generate a zip file for each cacheably assembly.
In the project References folder in Visual Studio, select the referenced dll that you don't want to be loaded again, and in the Properties window set its Copy Local property to false.

How to use the .def file for explicit linking?

I am facing the the problem to link to a third party dll. It is windows mobile application, where I am try to link to this third party dll.
Here first I had the dll and lib file. I was not able to link to it explicitly, but implicit linking is working. In the explicit linking the getprocaddress was failing. The dumpbin showed only the dllmain functions being exposed and no other function being exposed, hence the getprocaddress was failing.
However my application doesnot start if the dll is not found/installed in the device. It is expected as it is imlicit linking of a dll hence my application does not start.
I reported this to the third party dll provider and said that I want the explicit linking as the dll takes more space in my application if it is linked implicitly.
They replied by providing the .def file and said that I can use this .def file in my app to explicitly link to a dll.
I don't know how to use this .def file to explicitly link to a dll. Can any one please explain briefly about how to use this .def file in my app to explicitly link to a dll.
Use the *.def file when you build the DLL, to specify what function names the DLL is supposed to export.
After the DLL is built, use dumpbin /exports to verify that the functions are indeed exported from the DLL.
After you have verified that the DLL is exporting functions, you can either link to them at run-time using LoadLibray/GetProcAddress, and/or you can link to them at build-time by passing the DLL's *.lib file (which was created when you built the DLL using its *.def file) as an argument to your application's linker.