Error C1189 #error: MFC does not support WINVER less than 0x0501. Please change the definition of WINVER in your project properties or precompiled header.
I redefined these macro in stdafx.h, but forgot to remove old ones below it. so old ones are still valid. remove the old one, then everything is good: error message disappeared:)
-
MFC does not support WINVER less than 0x0501
I had a similar problem, and no amount of #define fixed it. Turns out, in Visual Studio 2013, if you right click on your project, select properties, then in the options Configuration Properties -> C/C++ -> All Options, there was a /DWINVER there. – thejinx0r Mar 4 '15 at 3:43
@thejinx0r There is no such option in VS2017. But you can still do this by adding like "/DWINVER=0x0603" into Configuration Properties -> C/C++ ->Command Line->Additional Options –
In my case my project had a source file with name stdafx.h, inside that file there was:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0500
#endif
I changed it to:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x601
#endif
By default WINVER is defined as 0x0500 in preprocessor. To overcome from this error, remove defined win version "WINVER=0x0500" from Configuration Properties => c/c++ => Preprocessor tab and rebuild.
Or you can provide higher WIN VERSION as #define _WIN32_WINNT 0x601 in your code wherever you getting error.
-
Update WINVER and _WIN32_WINNT Update WINVER and _WIN32_WINNT
To modify the macros, in a header file (for example, in targetver.h, which is included by some project templates that target Windows), add the following lines.
#define WINVER 0x0A00
#define _WIN32_WINNT 0x0A00
The macros in the example are set to target every version of the Windows 10 operating system. The possible values are listed in the Windows header file sdkddkver.h, which defines macros for each major Windows version. To build your application to support a previous Windows platform, include WinSDKVer.h. Then, set the WINVER and _WIN32_WINNT macros to the oldest supported platform before including sdkddkver.h. Here are the lines from the Windows 10 SDK version of sdkddkver.h that encode the values for each major version of Windows:
-
Upgrade C++ projects from earlier versions of Visual Studio
-
Overview of potential upgrade issues (Visual C++)
-
Upgrade your code to the Universal CRT
-
Update WINVER and _WIN32_WINNT
-
Fix your dependencies on C++ library internals
-
Floating-point migration issues
-
Use native multi-targeting in Visual Studio to build old projects
-
C++ features deprecated in Visual Studio 2019
-
Microsoft C++ porting and upgrading guide
-
Visual Studio IDE tools for upgrading C++ code
-
Microsoft C/C++ change history 2003 - 2015
-
Visual C++ What's New 2003 through 2015
-
C++ binary compatibility between Visual Studio 2015, 2017, and 2019
-
Porting and Upgrading: Examples and Case Studies
-
Porting Guide: MFC Scribble
Step 2. Getting it to build
Before building, we check the platform toolset so we know what compiler version the project system is using. In the project properties dialog, under Configuration Properties, in the General category, look at the Platform Toolset property. It contains the version of Visual Studio and the platform tool version number, which in this case is v141 for the Visual Studio 2017 version of the tools. When you convert a project that was originally compiled with Visual Studio 2010, 2012, 2013 or 2015, the toolset is not automatically updated to the latest toolset.
To make the switch to Unicode, open the project's properties, under Configuration Properties, choose the General section, and locate the Character Set property. Change this from Use Multi-Byte Character Set to Use Unicode Character Set. The effect of this change is that now the _UNICODE and UNICODE macros are defined and _MBCS is not, which you can verify in the properties dialog under the C/C++ category at the Command Line property.
Now build the solution. In the output window, the compiler tells us that _WINNT32_WINNT is not defined:
Output
_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
This is a warning, not an error, and is very common when upgrading a Visual Studio C++ project. This is the macro that defines what the lowest version of Windows that our application will run on. If we ignore the warning, we accept the default value, _WIN32_WINNT_MAXVER, which means the current version of Windows. For a table of possible values, see Using the Windows Headers. For example, we can set it to run on any version from Vista onwards.
Step 3. Testing and debugging
There is no test suite, so we just started the app, tested its features manually through the UI. No issues were observed.
Step 4. Improve the code
Now that you've migrated to Visual Studio 2017, you might want to make some changes to take advantage of new C++ features. The current version of the C++ compiler is much more conformant to the C++ standard then previous versions, so if you have a mind to make some code changes to make your code more secure, and more portable to other compilers and operating systems, you should consider some improvements.
-
Using the Windows Headers
-
Predefined Symbol IDs
When you begin a new project, depending on the project type, some symbol IDs are predefined for your use. These symbol IDs support the various libraries and project types such as MFC. They represent common tasks that are usually included in any application, or actions of hardware items, such as a mouse or printer.
These symbol IDs become important when working with resources. They are available when you edit accelerator tables and some of them are already associated with virtual keys. They're also available to you through the Properties window. You can assign any of the predefined symbol IDs to new resources, or you can assign accelerator keys to them and the functionality associated with the symbol ID automatically associates with that key combination.
-
Win32 Predefined Symbols
-
MFC Predefined Symbols
MFC projects always include several header files that support windows. These are added via #include statements in the StdAfx.h file:
#include < afxwin.h > //MFC core and standard components
#include < afxext.h > //MFC extensions
#include <afxdisp.h > //MFC automation classes
#include < afxdtctl.h > //MFC support for Internet Explorer common controls
#include < afxcmn.h > //MFC support for Windows common controls.
The header files include symbol ID values for MFC common values. These symbols are only available when you're working in an MFC project. The AFX_ prefix is followed by the standard symbol name prefixes.
-
Porting Guide: Spy++
This porting case study is designed to give you an idea of what a typical porting project is like, the types of problems you might encounter, and some general tips and tricks for addressing porting problems. It's not meant to be a definitive guide to porting, since the experience of porting a project depends very much on the specifics of the code.
Spy++:
Spy++ is a widely used GUI diagnostic tool for the Windows desktop that provides all sorts of information about user interface elements on the Windows desktop. It shows the complete hierarchy of windows and provides access to metadata about each window and control. This useful application has shipped with Visual Studio for many years. We found an old version of it that was last compiled in Visual C++ 6.0 and ported it to Visual Studio 2015. The experience for Visual Studio 2017 or Visual Studio 2019 should be almost identical.
We considered this case to be typical for porting Windows desktop applications that use MFC and the Win32 API, especially for old projects that have not been updated with each release of Visual C++ since Visual C++ 6.0.
Step 3. Linker OutputFile setting
Older projects sometimes have files placed in unconventional locations that can cause problems after upgrading. In this case, we have to add $(SolutionDir) to the Include path in the project properties to ensure that Visual Studio can find some header files that are placed there, rather than in one of the project folders.
MSBuild complains that the Link.OutputFile property does not match the TargetPath and TargetName values, issuing MSB8012.
warning MSB8012: TargetPath(...\spyxx\spyxxhk\.\..\Debug\SpyxxHk.dll) does not match the Linker's OutputFile property value (...\spyxx\Debug\SpyHk55.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).warning MSB8012: TargetName(SpyxxHk) does not match the Linker's OutputFile property value (SpyHk55). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
Link.OutputFile is the build output (EXE, DLL, for example), and it is normally constructed from $(TargetDir)$(TargetName)$(TargetExt), giving the path, filename and extension. This is a common error when migrating projects from the old Visual C++ build tool (vcbuild.exe) to the new build tool (MSBuild.exe). Since the build tool change occurred in Visual Studio 2010, you might encounter this issue whenever you migrate a pre-2010 project to a 2010 or later version. The basic problem is that the project migration wizard doesn't update the Link.OutputFile value since it's not always possible to determine what its value should be based on the other project settings. Therefore, you usually have to set it manually. For more details, see this post on the Visual C++ blog.
In this case, the Link.OutputFile property in the converted project was set to .\Debug\Spyxx.exe and .\Release\Spyxx.exe for the Spy++ project, depending on the configuration. The best bet is to simply replace these hardcoded values with $(TargetDir)$(TargetName)$(TargetExt) for All Configurations. If that doesn't work, you can customize from there, or change the properties in the General section where those values are set (the properties are Output Directory, Target Name, and Target Extension. Remember that if the property you are viewing uses macros, you can choose Edit in the dropdown list to bring up a dialog box that shows the final string with the macro substitutions made. You can view all available macros and their current values by choosing the Macros button.
more to take note ....
-
Visual Studio 2010 C++ Project Upgrade Guide
-
MSBuild Task:: Visual C++
-
VC++ Directories
Life in VS 2008
To start with, let’s take a look at the VS 2008 feature of VC++ Directories. If you were to go to the Tools->Options menu, you would see the following under the Project and Solutions settings
These are the IDE equivalents to the command line environment variables of PATH, INCLUDE, etc. However, these values only apply within the IDE or vcbuild.exe – they don’t apply when executing cl.exe, for example, directly from the command line. Additionally, as you can see from the Platform dropdown at the top of the dialog, you can customize these settings for each platform.
The implementation for these settings is to store the values in the VCComponents.dat file stored in %LOCALAPPDATA%\Microsoft\VisualStudio\9.0. Looking at the file, you’ll notice two things. First, it is in the LocalAppData directory, which means the settings are per-user, per-machine. The second thing you’ll notice is that the file is in an INI format, not the XML of a .vcproj file. This shows that the importing of the .dat file is some custom code of vcbuild.exe and the IDE.
Changes in VS 2010
The first thing you’ll notice in VS 2010 when working with VC++ Directories is that they appear to have disappeared. When you go to the Tools->Options window and look in Project and Solutions, you’ll see the window looks very similar to the screenshot above – only VC++ Directories is gone. However, if you bring up a VC++ project in the IDE and open the project properties window (right-click on the project node and select Properties), you will notice a Rule called VC++ Directories (Rules are the tree of selections on the left pane of the property page window) and that the values you see are the same defaults that you would get from VS 2008. Additionally, you can edit these properties in the same way as any other project property (including using the macro editor as shown – something not possible in VS 2008).
Of course, any edits you make right here are applied directly to the project you are working on – and directly to the project file itself. This means that the edits are NOT per-user, per-machine as they were in VS 2008. However, that option still exists in the form of a property sheet (If you don’t know about property sheets or how they work in VS 2010, I recommend reading my previous post about them here).
If you open up the Property Manager view to see the property sheets associated with your project, you’ll see that one of the property sheets is named Microsoft.Cpp.Win32.User. This property sheet is actually stored in LocalAppData, just as VCComponents.dat file was, in the directory %LocalAppData%\Microsoft\VisualStudio\10.0. Using the property editor on the property sheet (just right-click on this property sheet node and select Properties…), you can see that you are able to make edits directly to this file. Since all projects, by default, import this property sheet, you are effectively editing the VC++ directories in the same way you were able to do before.
Additionally, you can also delete the reference to this per-user, per-machine property sheet and create your own set of property sheets that set these values. Deleting the reference to this property sheet makes your project operate independently of any per-user, per-machine settings – and important step when trying to ensure correct behavior in a SCC (source code control) environment.
-
How To Display XML Code as Plain Text in Blogger
-
Enable C++ project system logging
-
MSBuild Syntax and the IDE
-
Kate Gregory's Blog
-
