I've a DLL file that is compiled with visual studio 2008 (suppose stub.dll), I know the exported function signatures of this DLL, but I don't know about it's internal implementation.
This DLL itself uses some other exported functions from another DLL which I should write (suppose server.dll)
I'm writing my server.dll in visual studio 2013 & export all desired functions correctly, my test programs can use exported functions without any problem, but when I want to use stub.dll it failes to load dynamic library.
Since I've no access to it's source, so I can't debug it to find where the problem is, but I guess it should be some kind of incompatibility between various versions of compiler or linker that I can't use server.dll within stub.dll (just about calling convention, I'm sure both of them use _stdcall calling convention).
any idea?
Related
I'm new to the world of .NET and I'm trying to understand the build process. If the concept of DLLs is to resolve references at run time why does visual studio need to to know about DLLs at compile time in order to build an executable ? Can't seem to find a definitive answer anywhere.
DLLs are loaded at runtime so your code can call code in that DLL, indeed. However, they are also needed at compile time so you can write code calling into that library.
Back in C++ I think that was done with .lib files or via COM, so the compiler didn't actually need the DLL. In .NET that's different because the DLL contains the code to run and the interface so other programs can use it.
I'm writing a simple C++ application in Visual Studio. It also has a setup project.
It works well on my development machine, but when I'm installing this application on user's machine it requires Visual C++ Redistributable Package. I'm wondering why does my application require C++ Redistributable? Standard C++ runtime library is shipped with Windows, isn't it?
The only version of the C runtime library which is shipped by Microsoft with most of 32 bit Windows versions is msvcrt.dll. This library provides a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, etc.
Visual Studio 6.0's compiler links against this library, so if you are developing in VS 6.0 you shouldn't encounter any problems on most users' machines.
However, if you are developing in VS 2005, VS 2008, VS 2010, VS 2012, VS 2013 or VS 2015, you have to distribute additional C runtime libraries along with your application. This is because their compilers link against msvcrt80.dll, msvcrt90.dll, msvcrt100.dll, msvcrt110.dll, msvcrt120.dll and msvcrt140.dll respectively, which are not shipped with Windows.
Solutions:
Possible solution is to link statically with runtime library, but it may cause a lot of problems in case you have both .exe and .dll in your application. Don't do that.
To be more specific, I'll allow myself to quote a part of this answer:
Using /MT is risky if you create DLLs as well as an EXE. You'll end up
with multiple copies of the CRT in your program. This was especially a
problem with earlier versions of VS where each CRT would get its own
heap, not so much with VS2012. But you can still have ugly runtime
problems when you have more than one "errno" variable for example.
Using /MD is highly recommended to avoid such lossage.
Another possible solution is to require an appropriate Microsoft Visual C++ Redistributable package to be installed on the user's machine.
It may be done by specifying this requirement in prerequisites property in your setup project.
Also, you can distribute the runtime dll by including in your setup project the appropriate "merge module". In this case don't forget to add the appropriate "policy merge module" to avoid errors caused by incorrect runtime version.
Finally, you can just put required DLLs in the same folder in which your application is installed.
Further reading:
"Redistributing Visual C++ Files" - Official MSDN documentation
Even though some comments said that «link statically with runtime library, but it may cause a lot of problems when you have both .exe and .dll in your application.» this is NOT TRUE. First we DON'T statically link DLLs! We statically link OBJs and LIBs. LIBs are static libraries; DLLs are dynamic libraries, and you may choose to use LIBs (static) or DLLs (dynamic). It's entirely up to you to choose. The ONLY drawback (for the DLL fans) is that if you want to update one library, you need to compile and link again. I personally deploy ALL my software static linked and because of that I earn the bonus of don't even need installers. The software I develop is 100% portable (a feature that in the pre-installer era was general procedure), and the final user is free to simple COPY from one folder to another or even from the hard drive to flash drive (or vice-versa). The error message «DLL not found.» simply doesn't exist ... NEVER.
Some folks think of statically linking as toy software: WRONG! I can write a full featured application that connects to a DBMS (Oracle, SQL Server, ...) or any other kind of application.
i am using microsoft visual studio 2010 for developing an application. Additionally I am using the QT3D library as an external library.
The QT 3D library is sucessfuly installed and integrated with visual studio. I know this because I can compile and run the examples.
but when I try to write my own code, the visual studio compiler gives me the following error
c4272 : 'function' : is marked __declspec(dllimport); must specify native calling convention when importing a function.
The error message is received a few hundred times, for each of the member functions which are present in the classes in the library header files.
I suspect, that problem has something to do with the linking of the libraries. In the Additional include files the Path is given as follows
"$(QTDIR)\include";"$(QTDIR)\include\Qt3D";"$(QTDIR)\include\QtGui";"$(QTDIR)\include\QtCore";".moc\debug_shared";$(QTDIR)\mkspecs\win32-msvc2010;%(AdditionalIncludeDirectories)
When I iclude the header files, the auto complete option can detect these libraries.
the additional library file paths are given as follows.
$(QTDIR)\lib;C:/qt/5.0.1-x64/qtbase/lib;%(AdditionalLibraryDirectories)
any ideas?
Best Regards
tdk.
I have a .dll file produced with Visual Studio 2005 (unmanaged C++). In various functions within the DLL, I can detect errors and call another function within the DLL to produce a minidump (using dbghelp.dll) .
This works perfectly when the application using the DLL is also a VS2005-produced program. However, when I use National Instrument Measurement Studio/CVI to produce the application (in plain C, not that it should matter), it does not get a .pdb file (surprise!). As a result, when I open the generated .dmp file with VS2005, it tells me the application was not built with debugging (but it was!) and the stack shown is useless.
Many (40+) other functions in this DLL are successfully used by the CVI application. This would seem to demonstrate the successful access of the DLL functions from the non-VS application.
National Instruments apparently can use a full dump from DrWatson, so it must be possible.
Does anybody know how to get what is needed for using the .dmp file?
To summarize: No .NET, function access is fine, generated minidump files do not seem usable by Visual Studio.
Thanks for your help.
You must have symbols (at least dllexports) to be able to analyze the dump file. Try use Debugging Tools for Windows (WinDBG) to open the minidump file and see what you've got. WinDBG does a much better job analyzing dumps than VisualStudio 2005.
I have a communication library built on top of Qt and Google Protocol Buffers. It's currently being built with MinGW/GCC on Windows. My goal is to use the same library in C# on .NET, with the help of a thin wrapper on top using C++/CLI (bridging the unmanaged code with managed code).
I tried using the MinGW produced DLL directly in my C++/CLI project, but I keep getting linker errors (cant remember the error codes right now, but something about missing tokens and functions/signatures).
First question is: Should I be able to use the MinGW-produced DLL with the Visual Studio compiler/linker? Or do I need to compile the library again, using only VS compiler for all projects?
If I should be able to use the MinGW-produced DLL directly, how do I reference it in Visual Studio 2010? In project settings it seems to look for *.lib files, but I can't find any .lib files in the output of MinGW/GCC. It does produce *.a files, but it seems like Visual Studio don't handle this kind of file..
I should also mention that both Qt and protobuf are also compiled with MinGW. But I can of course recompile all the parts in VS 2010 if necessary.. Would have been nice to save the recompile time though, since our buildserver already has a working setup using MinGW.
The easiest way to use it would be by recompiling it with Visual Studio. This is when I am assuming C++ types and classes used in the interface you intend to use.
In case you have a C interface to this library you could dynamically load the library via LoadLibrary and use GetProcAddress to access those functions.
However it depends completly on the way how you intend to use the library.