We have developed a C++ library that does a little bit of data interpretation, mostly converting raw byte streams into JSON strings and also collecting raw data packages and returning the collection as a binary file (byte stream).
This library is written with pure C++ STL without any other libraries as dependencies and is used successfully in Android and iOS projects.
For a new C# project for Windows Desktops, developed by external partners we have built, a PIMPL class in C++/CLI that enables easy integration of the already existing code base. In Visual Studio we compile the C++ library into a static library with clang/LLVM and use it in the Visual C++/CLI Wrapper project as a dependency to build a DLL that we provide for our partner.
This setup took a little time but it works now fine and we are really happy about the development.
But when we tried to get a Demo running on a different PC we encountered serious problems: It is not possible to load this DLL on a "clean" system. When trying to load it in our application (or a DLL Dependency Walker for that matter) it throws a
After some hours of experimenting I've narrowed it down to the Windows 10 SDK that seems to be necessary to load this DLL.
My guess is that it has something to do with some compiler/linker setting in Visual Studio, but I have no idea which one...
Edit:
All VC++ redistributables (2010-2017, x86&x64 just to be sure) as well as the .Net Framework 4.7 and .Net Core Redistributable are installed.
Related
I am trying to build a few different 32-bit C++ applications with Visual Studio 2015 that use CEF. To use CEF, I am currently acquiring the CEF prebuilts from Spotify. The dll wrapper for CEF is built using Visual Studio 2015 with some modifications to its CMake files to force it to build with MD and MDd mode regardless of other settings. This was sufficient to make these C++ applications run on some machines. Any machine on which Visual Studio 2015 is installed on before anything else they can run on, however some machines seem to exist in a state such that the program will produce an error on starting when lacking the MSVC 2015 runtime (as expected), but when adding the MSVC 2015 runtime the program simply crashes; however, it only crashes after CEF is used. These programs work fine when they don't link to libcef.dll and don't include the browser functionality.
Upon investigating, I found that libcef.dll, as built by spotify, links to MSVCP110_WIN.DLL, which is from the Visual C++ 2012 Redistributable package. Naturally, the application I am building links to MSVCP140.DLL, which is from the Visual C++ 2015 Redistributable package. This means that the application ultimately links to two runtimes simultaneously. I do not know if this is an issue, but so far it seems to be my best lead. Installing the Visual C++ 2012 Redistributable does not change the outcome and it continues to crash when CEF is used.
This issue has been witnessed on both Windows 7 and Windows 10 and the application works without CEF on both of those operating systems as well, so the operating system is not likely to be the cause of the failure on these systems specifically.
Has anyone else encountered this issue and does anyone know a workaround? Also, does anybody know if it is okay to mix these two runtimes and what the limitations are? It seems that the installation history of a given machine affects the success of running the application, so any hints into what combination of things leads to this failure would be helpful as well.
You have some options:
Use the lastest version of VS that will allow a selection of Platform Toolset that matches libdef.dll. For example, VS2013 might allow the selection of the 2012 CRT.
Or convince Spotify to rebuild libcef.dll such that it matches your version of CRT
Or convince Spotify to not release libraries that depend on the CRT (yes that's probably a bit of work).
Or make a small app built against the older CRT, this app can then successfully use libcef.dll. Then you get to use any IPC technique so that your main VS2015 app can talk to this wrapper. Running out-of-process is one way to segregate the unruly third party libraries.
EDIT:
This is open source? Well good news, you can fix this yourself, built the CEF against your favorite version of VS.
In my DirectShow application I have a third party DLL (a 32bit DirectShow filter) that I don't have source for that links against the 32bit Windows version of Intel Threading Building Blocks (tbb.dll).
If I want to use Threading Building Blocks in my own DLL in the same process (e.g. another 32bit DirectShow filter) does this force me to use the same version of Visual Studio that the author of this third party DLL used?
EDIT - I've realised that the version independent _mt library is probably the best one to use in this scenario. What happens if third party vendors haven't built for this _mt dll?
In my own Threading Building blocks installation I notice that there are different versions of tbb.dll for different versions of Visual Studio - 2005, 2008, 2010 and 'MT' (not sure what that is yet). One obvious reason for this is that the different versions of tbb.dll link against different versions of the Visual Studio runtime library DLLs. Is it possible to tell which version of tbb.dll is required by inspection or do I have to grub around looking for strings in the binary indicating the compiler version used (the third party DLL appears to be linking the visual studio runtimes statically)?
As far as I can tell tbb.dll doesn't use manifests and side by side versioning and is given the same name for different compiler versions. A last resort would be to rename the different tbb.dlls and hack the import library or imports to reference the renamed dlls but I'd really rather avoid this. Is there a clean way to redirect the imports with linker options?
As these DLLs are well behaved DirectShow filters they won't be passing Visual Studio runtime or TBB objects between them which would clearly be dangerous. Their interaction will be limited to calling each other via standard COM DirectShow calls.
If you are not using TBB, the question is only about Visual Studio versions, then you don't have to worry: Visual C++ Runtime DLLs have different names across versions, e.g. MSVCR70.DLL, MSVCR90.DLL etc. And, as you already discovered, /MT switch will compile/link a static version of runtime and will embed the stuff into your DLL without having to worry about sharing right DLL with a peer DLL.
If I built my app against D3DX June2007_d3dx9_34 and the target system has a newer version Nov2007_d3dx9_36 should that be a problem?
I distribute D3DX DLLs using MS' redist-installer tool but I noticed one one 'clean' PC (no D3DX previously installed) I got an error about missing D3DX DLL. Before trying to figure out if the installer itself is not working, I wondered if maybe supplying a too-new version of the DLL is the problem - will the app be looking for a DLL with the exact name?
D3DX libraries are not backwards-compatible, and the API may change between versions. So the target system must have the same version of D3DX that you build your application with - a newer version won't work.
If you use Dependency Walker on your application, it should show you that there's a dependency on a DLL with the exact version number.
The redistributable in the DirectX SDK includes the whole history of the D3DX dlls. Installing the latest version of the DirectX redistributable should have your system end up with every version of these dlls. It is possible and allowed for applications to only install the files they need by deleting cab files out of the redistributable's directory structure, in order to reduce the size of the redistributable components, and this is how you can end up with having 43 of the dll but not 37 for instance.
If you remove the dependency of D3DX and D3DCOMPILER dll's from your application you can ensure the application will work as the d3d9 d3d10 and d3d11 core dlls are version-agnostic and are also tied to the windows service pack releases (i.e. D3D11 for Vista comes from Vista SP2 or Win7 stock installs for example).
Another possible way to remove the dependency and let the app startup is to make the dll a delay load module, so it is only loaded when needed (such as compiling shaders on a development environment). As long as you are sure the shaders exist on end-user machines properly it won't need to compile shaders and won't crash. Calling LoadLibrary and invoking the functions manually would be a safer choice with a way better error message of your choosing, but is a lot more work.
I've just recently started working with Visual Studio this summer, primarily on CUDA and OpenCV related projects. Prior to this, I had been doing my development on Linux for CUDA using Makefiles and the common.mk makefile from NVIDIA.
So my question is as follows: I've not been able to figure out for the life of me what the difference between some of the different project templates are. I know that I've had to use "Empty Project" from the general tab of the Visual C++ options, but that's more trial and error, rather than actually knowing what is going on...
A Win32 project is used if you want to end up with a DLL or a Win32 application usually using the bare WinAPI. A common language runtime (CLR) project is used to create C++/CLI project, i.e. to use C++/CLI to target the .NET platform.
The main difference between projects is what Visual Studio comes up with in terms of pre-created files. A windowed Win32 application for example (what you get when you choose Win32 project, but not a DLL) is created with a file for resources (menus, accelerators, icons etc.) and some default code to create and register a window class and to instantiate this window.
When creating a Win32 project, the linker Subsystem is set to Windows. When creating an empty C or C++ project the subsystem is set to console. Likewise the entry point in the settings for Win32 projects expects a WinMain or DllMain while a console expects an int main. A CLR allows you to mix C++ and .NET which is usually discouraged against.
A Windows subsytem can target executables, dlls, libs or driver/native(sys) files. While a console subsystem targets console binary executables. WinMain is typically used when creating an actual Window application using the CreateWindowEx API, establishing message callbacks and inserting a message handler loop.
A console subsustem with int main can also create a Windowed application only you're better off doing it with WinMain.
A Dll empty project sets the subsystem to Windows and setting to the compiled output to (.dll) as well as the entry point to DllMain/APIENTRY and a static lib will do the same as the Dll except it will set the output to (.lib).
Setting the project to Native subsystem will require the Windows Driver Development Kit to compile drivers.
I need to compile some mfc code that was written using Visual C++ 6.0 many years ago. I was supposed to be able to choose New->Project->Win32 Application and then in Project->Settings choose "Using MFC as a static library." I'm using the AE version and this could be the reason that this option is not available. So far, the smaller programs compile using the "Use MFC as a shared dll", but I'd like to have or mimic the other option. Any suggestions?
I would guess (not 100% sure, but pretty sure) that the Academic Edition corresponds to the featureset of the Standard Edition of Visual Studio 6.0. If that is the case, that version does not support static linking to MFC:
http://msdn.microsoft.com/en-us/library/aa261791%28VS.60%29.aspx
I would suggest upgrading to one of the new Visual C++ Express products. They're free, plus you'll get a newer compiler that's free of many of the restrictions you have with the older package.
Edit
The commenter below correctly mentions that the Express editions don't come with MFC, so I guess your option is to either link to MFC dynamically or upgrade to a version that supports static linking.
If you don't absolutely need static linking for some reason, I suggest dynamic linking. VC 6-era MFC libraries have been part of the O/S for ages, so you'll actually be building smaller executables and shouldn't have any redistribution issues by doing so.