I'm having a little trouble building my application as Release in Visual Studio 2008. It builds fine without any errors or warning as Debug. The application is primarily Win32 with a little MFC and ATL mixed in here and there. Most of the projects in the solution generate a LIB and DLL.
This is one of the errors I am getting:
fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
My application is a multithreaded DLL, so the /MD needs to stay. The only Windows includes are these:
#include "stdafx.h"
#include "afx.h"
#include "WMIQuery.h"
#include "SerialPort.h"
The other error is this:
fatal error C1083: Cannot open include file: 'WMIQuery.h': No such file or directory
This one really doesn't make sense to me because, the environment has no problem finding this file building for Debug.
Does anyone know how to fix this? If any additional information is needed, just say so, and I'll post. Thanks.
The project property changes you've made to get it to build in the Debug configuration are not automatically applied to the Release configuration as well. Note the "Configuration" combo in the upper left corner of the dialog. Altered property values are shown in bold type.
If you cannot remember what changes you've made then open the .vcproj file in a text editor like Notepad.exe. The settings that were changed from their default value are listed in the Debug|Win32 configuration section.
The first error is most likely a mismatch in your project settings. Since you require /MD, check your project configuration properties for release, under the 'General' heading. There should be an item "Use of MFC". This should be set to "Use MFC in a Shared DLL".
The second error is probably due to a mismatch in include paths between the two configurations.
Double-check your environment variables. I believe it uses separate values for debugging and releasing.
Related
I'm trying to make my C++ into a .lib file to use with my projects.
I have the files Log.h and Log.cpp.
I went into my project properties in Visual Studio and changed the configuration type from .exe to .lib. I set the build mode to Release and built my class into a file called Log.lib.
In a new C++ project, I'm trying to include that .lib file I made along with the Log.h file. All was successful, it recognised my functions, but when I try to run my exe program with my included Log.h, I get the following errors:
mismatch detected for '_ITERATOR_DEBUG_LEVEL':
value '2' doesn't match value '0' in main.obj
By referencing this stackoverflow post, I discovered that building and running my new project in Release mode (the same as the .lib mode) removes the errors and I can successfully run my program and use the Log.h.
How can I compile my Log.h lib to be compatible with both Debug and Release?
You have a mismatch in the version of the C runtime library that your projects are linking to. One of the projects is linking to the debug version of the CRT, while the other one is linking to the release version of the CRT. That mixed configuration is not supported, and it is resulting in the error message. The standard library template classes are actually different in debug and release builds.
You need to check the settings for all of your projects (everything that generates either an EXE or a LIB file as output), and ensure that they are all using the same version of the CRT. This is the /MT or /MD switches passed to the compiler.
It is not possible to build your lib to be compatible to Debug and Release C runtime library (CRT).
See also here.
But it is possible to change the version of the CRT in your exe project: If both the debug and release configuration use the same version of the CRT (e.g. Multi-threaded DLL (/MD)) you can build your lib in release configuration and use it in release and debug configuration of your exe program (which will result in poorer debug support).
To change the runtime library in Visual Studio, open the Project Properties and go to "C/C++" - "Code Generation" - "Runtime library" (this depends on the version of Visual Studio you use, but should at least be valid for VS2010-2015).
I am using a VS2015 to create DLLs which will be used in a project (which will be run on another PC).
I have build the DLLs in Release version on my PC but when I start the project on another PC, I get following errors:
VCRUNTIME140D.dll is missing
MSVCP140D.dll is missing
MSVCP140D.dll is missing
What steps should I take while creating these DLLs so that these debug runtime DLLs won't be required to the run the project on any PC.
In spite of it being built in release mode, if you require "...D.dll", then there are debug builds in the mix.
This could be the result of the third party dll you have or there are DEBUG or _DEBUG defines floating around.
Most likely is that the build (of the dll or the host exe) is explicitly set to use the debug version of the runtime (/MDd). Change this in the project settings to not use the debug version of the runtime (/MD).
Open the project's Property Pages dialog box.
Expand the C/C++ folder.
Select the Code Generation property page.
Modify the Runtime Library property.
To assist in the diagnosis of which binary is responsible for the debug dependency, you can use Dependency Walker to track down the offender. It will give you a list (as a tree) of the dependencies of each file.
In general, for missing the C++ runtimes (release version) on a target machine, you should install the C++ redistributable. As of this writing, VS 2015 redistributable is available here.
In C/C++ -> Code Generation -> set Runtime Library to:
Multi-threaded Debug (/MTd)
And yes, such setting is very much needed if you want to debug a process on a remote machine. So, don't go by others saying, "test with Release build only". Obviously, you'll need Remote Tools installed.
As stated by Niall, you should use dependency walker in order to find which part of the project is causing the error, it might not be the dll in issue after all.
My bet is it's just some part of the project you forgot and built in debug mode, which of should never be used for production as debug dlls are not included in C++ redistrib installers.
I'm using Visual Studio 2013, with the 2012 toolset and I'm trying to split an win32 executable project up into an exe that consumes a dll that contains all the program logic. The end goal is to be able to create a seperate project for unit tests that can link against the new dll.
Now the old version of the project compiles absolutely fine and uses cryptlib.lib (thanks SVN!), but once I separated it out in to a dll with the program logic and the same project settings I get the following error when I attempt to build the dll:
Error 546 error LNK1104: cannot open file 'cryptopp.lib'
I have the directory that contains cryptlib.lib in my linker settings and I'm linking against it just as I did in the previous project settings. Based on the documentation it shouldn't be trying to link against cryptopp.lib because CRYPTOPP_DEFAULT_NO_DLL is defined in the preprocessor settings.
I also tried adding the directory that contains cryptopp.lib to the VC++ directory paths and I added cryptopp.lib to my linker settings, and it still gives me the same error. I don't want to use the dll version of cryptopp, but at this point I just need the thing to work.
All the projects are using the 2012 toolsets, and all are being compiled as win32 projects so I'm not sure where to go from here.
Well I figured out what was happening, if not why. For some reason the preprocessor definitions don't seem to be getting applied. If I put CRYPTOPP_DEFAULT_NO_DLL at the top of all the include files it works as expected.
I had a C/C++ Visual Studio 2013 Community Edition project that was defined to generate a DLL, and I'm having a lot of misery with "undefined symbols" which I wanted to use in another project, so I decided to see what it would give if I changed the project settings so that it would generate a static library instead.
So in the Properties window of the project I went to
Configuration Properties > General > Project Defaults > Configuration Type
and set the Configuration Type to Static Library
The target extension is .lib.
When I do a rebuild I still get a fresh dll file in my Release folder, as well as a lib, and the DLL file is much bigger than the lib file. This makes the lib file look like an "export lib" file and it looks like nothing has changed.
This still happens if I stop and restart Visual Studio.
Am I missing something or does this look like a bug to you?
In Configuration Properties - C/C++ - Runtime Library change setting to Multi-threaded (/MT) for Release configuration and to Multi-threaded Debug (/MTd) for Debug configuration.
Also, check Configuration Properties - General - General - Target extension is set to .lib.
Check settings for all configurations (Release and Debug if you use them).
Why have you changed your project type? If you need DLL, build DLL. Post exact errors received during DLL compilation. Perhaps you missed some dllexport/dllimport declspecs.
Regarding .lib: are you sure, that DLL is generated during build? Perhaps it is the output from previous (DLL) configuration? Have you tried to compile test app using this .lib? Perhaps it is valid and compiled properly?
Another matter: have you removed all dclspecs from function signatures after project type change? When building static library, none of them are applicable.
I'm using tinyxml library for parsing XML files in my project. When I try to target x64 platforms I get LINKER errors and here is one fo them:
Error 4 error LNK2001: unresolved external symbol "private: static
struct TiXmlString::Rep TiXmlString::nullrep_"
(?nullrep_#TiXmlString##0URep#1#A) ClassThatUsesTinyXML.obj
Update : I figured that the x64 version of tinyxml was not installed but when I tried to build the library for x64 platforms I got this error :
LNK1561: entry point must be defined
Instead of building tinyxml for x64 platforms and then adding tinyxml.h and tinystr.h to the project, I just added all the library files including the .cpp files and now I can target x64 platforms, the library is, in fact, being built when I build the whole project.
It does not look like tinyxml supports shared library builds out of the box.
Here are the steps that I followed to build a DLL from the tinyxml 2.6.2 sources:
Open the provided SLN file, tinyxml.sln, in MS Visual Studio Express 2012 for Windows Desktop. Elect to convert the old project files to the new format when prompted.
From "Solution Platforms", select "Configuration Manager..."
From "Active solution platform:" select "<New...>"
In "Type or select the new platform:" select "x64" if not already selected. Make sure to copy settings from the "Win32" configuration. Click OK. Click Close to exit the Configuration Manager.
Right click on the tinyxml project in Solution Explorer. Select "Properties".
For "Configuration:", select "All Configurations". Similarly, for "Platform:" select "All Platforms".
On the Configuration Properties → General page, change "Configuration Type" to "Dynamic Library (.dll)". Change "Target Extension" to ".dll". Click OK to exit the tinyxml Properties Pages dialog.
Select the "Release" configuration and "x64" platform.
Right click on the tinyxml project in Solution Explorer again and select "Rebuild".
Within tinyxml_2_6_2\tinyxml\x64\Release you will find tinyxml.dll, but no import library (tinyxml.lib). This is because no symbols are exported. See How do I build an import library (.lib) AND a DLL in Visual C++?
If you want to go the shared library route, you will need to export the desired symbols via the MSVC-specific __declspec(dllexport) modifier. See Symbol Visibility in Windows.
The errors occurs when you define TIXML_USE_STL for the compilation of the library, but not for the sources that link to the library. The end result is that the library is compiled with different code from the sources using the library.