C2011 ‘vc_sttributes::YesNoMaybe’ “ ‘enum’ type redefinition RESOLVED
-
Resolution: In the environment variables for include and lib there were three copies of one directory. That lead to the deletion of some other items. I suspect those three copies were the results of multiple upgrades and installs beginning with VS 2005. Windows 7, visual Studio 2010, C++, MFC I posted this on MDSD a week ago and have no replies. The essence is that definitions from within Visual Studio are showing up as being redefined. I do not have direct control over these and cannot find the indirect control / problem / defect that I have managed to insert in the code. Here is the first of a long list of errors in the Output window
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionFirst, I cannot copy/paste from my working computer to my internet computer so please excuse any typos. If you see one, feel free to mention it as there may be an error, but please do not reject everything out of hand due to typos. I searched for this problem and found several results, including an unanswered question from 2008 here: https://social.msdn.microsoft.com/Forums/en-US/fb887af6-45dc-42b9-94bb-ab4d08a16dd8/64bit-compiler-error?forum=Vsexpressvc It included advice to clean and rebuild. Following said advice I did a “Clean.” Then I closed Visual Studio entirely and ran a batch file I have named clean.bat that deletes 14 types of files in the solution directory and all subdirectories followed by a rebuild. A restart of VS and a build produces the same problem. The titular error and similar errors are repeated numerous times. Edit: to complete the title the entire error is (with a couple of CRs added for readibility:
1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionMuch further down in the error list is found: … message_constants.h(50): error C2370: ‘NO_NAME_SPECIFIED’ : redefinition; different storage class That particular file begins with #pragma once The constant is referenced one time only in the entire project, and that reference is within the same file. So,…, I surmise that the #pragma once is not working. Maybe I did something to defeat it, I don’t know. So, …, I added these lines to the start of the file, just below the pragma once
#ifndef MESSAGE_CONSTANTS
#define MESSAGE_CONSTAN -
Resolution: In the environment variables for include and lib there were three copies of one directory. That lead to the deletion of some other items. I suspect those three copies were the results of multiple upgrades and installs beginning with VS 2005. Windows 7, visual Studio 2010, C++, MFC I posted this on MDSD a week ago and have no replies. The essence is that definitions from within Visual Studio are showing up as being redefined. I do not have direct control over these and cannot find the indirect control / problem / defect that I have managed to insert in the code. Here is the first of a long list of errors in the Output window
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionFirst, I cannot copy/paste from my working computer to my internet computer so please excuse any typos. If you see one, feel free to mention it as there may be an error, but please do not reject everything out of hand due to typos. I searched for this problem and found several results, including an unanswered question from 2008 here: https://social.msdn.microsoft.com/Forums/en-US/fb887af6-45dc-42b9-94bb-ab4d08a16dd8/64bit-compiler-error?forum=Vsexpressvc It included advice to clean and rebuild. Following said advice I did a “Clean.” Then I closed Visual Studio entirely and ran a batch file I have named clean.bat that deletes 14 types of files in the solution directory and all subdirectories followed by a rebuild. A restart of VS and a build produces the same problem. The titular error and similar errors are repeated numerous times. Edit: to complete the title the entire error is (with a couple of CRs added for readibility:
1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionMuch further down in the error list is found: … message_constants.h(50): error C2370: ‘NO_NAME_SPECIFIED’ : redefinition; different storage class That particular file begins with #pragma once The constant is referenced one time only in the entire project, and that reference is within the same file. So,…, I surmise that the #pragma once is not working. Maybe I did something to defeat it, I don’t know. So, …, I added these lines to the start of the file, just below the pragma once
#ifndef MESSAGE_CONSTANTS
#define MESSAGE_CONSTANbkelly13 wrote:
Question: What have I done wrong to incur such wrath upon myself?
You have been editing the compiler's files and altering the file names. If you don't understand the problem (and even if you do) then modifying these files is just crazy. You need to go backwards from the error message to try and find out where this enum is defined to cause the conflict. And the chances of it being some setting in the VC installation, rather than in your project, are extremely low.
-
Resolution: In the environment variables for include and lib there were three copies of one directory. That lead to the deletion of some other items. I suspect those three copies were the results of multiple upgrades and installs beginning with VS 2005. Windows 7, visual Studio 2010, C++, MFC I posted this on MDSD a week ago and have no replies. The essence is that definitions from within Visual Studio are showing up as being redefined. I do not have direct control over these and cannot find the indirect control / problem / defect that I have managed to insert in the code. Here is the first of a long list of errors in the Output window
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionFirst, I cannot copy/paste from my working computer to my internet computer so please excuse any typos. If you see one, feel free to mention it as there may be an error, but please do not reject everything out of hand due to typos. I searched for this problem and found several results, including an unanswered question from 2008 here: https://social.msdn.microsoft.com/Forums/en-US/fb887af6-45dc-42b9-94bb-ab4d08a16dd8/64bit-compiler-error?forum=Vsexpressvc It included advice to clean and rebuild. Following said advice I did a “Clean.” Then I closed Visual Studio entirely and ran a batch file I have named clean.bat that deletes 14 types of files in the solution directory and all subdirectories followed by a rebuild. A restart of VS and a build produces the same problem. The titular error and similar errors are repeated numerous times. Edit: to complete the title the entire error is (with a couple of CRs added for readibility:
1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionMuch further down in the error list is found: … message_constants.h(50): error C2370: ‘NO_NAME_SPECIFIED’ : redefinition; different storage class That particular file begins with #pragma once The constant is referenced one time only in the entire project, and that reference is within the same file. So,…, I surmise that the #pragma once is not working. Maybe I did something to defeat it, I don’t know. So, …, I added these lines to the start of the file, just below the pragma once
#ifndef MESSAGE_CONSTANTS
#define MESSAGE_CONSTAN1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionAre you compiling the file winocc.cpp? That is a MFC source file that must not be compiled by applications (it is part of the MFC DLLs). Regarding the file name cases: Windows file names are not case sensitive. While the case is preserved by the file system, it is ignored when opening files. As already mentioned by Richard: Never change any of the system include files.
-
Resolution: In the environment variables for include and lib there were three copies of one directory. That lead to the deletion of some other items. I suspect those three copies were the results of multiple upgrades and installs beginning with VS 2005. Windows 7, visual Studio 2010, C++, MFC I posted this on MDSD a week ago and have no replies. The essence is that definitions from within Visual Studio are showing up as being redefined. I do not have direct control over these and cannot find the indirect control / problem / defect that I have managed to insert in the code. Here is the first of a long list of errors in the Output window
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionFirst, I cannot copy/paste from my working computer to my internet computer so please excuse any typos. If you see one, feel free to mention it as there may be an error, but please do not reject everything out of hand due to typos. I searched for this problem and found several results, including an unanswered question from 2008 here: https://social.msdn.microsoft.com/Forums/en-US/fb887af6-45dc-42b9-94bb-ab4d08a16dd8/64bit-compiler-error?forum=Vsexpressvc It included advice to clean and rebuild. Following said advice I did a “Clean.” Then I closed Visual Studio entirely and ran a batch file I have named clean.bat that deletes 14 types of files in the solution directory and all subdirectories followed by a rebuild. A restart of VS and a build produces the same problem. The titular error and similar errors are repeated numerous times. Edit: to complete the title the entire error is (with a couple of CRs added for readibility:
1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinitionMuch further down in the error list is found: … message_constants.h(50): error C2370: ‘NO_NAME_SPECIFIED’ : redefinition; different storage class That particular file begins with #pragma once The constant is referenced one time only in the entire project, and that reference is within the same file. So,…, I surmise that the #pragma once is not working. Maybe I did something to defeat it, I don’t know. So, …, I added these lines to the start of the file, just below the pragma once
#ifndef MESSAGE_CONSTANTS
#define MESSAGE_CONSTANHmmmm,
bkelly13 wrote:
While trying to chase down this problem I discovered that the file name is really Message_Constants.h. When I chase down the error the file name at the top of the edit windows shows the name "message_constants.h" It also shows "Message_Constants.h" What is with the all lower case versus the leading caps? I execute a Save As to ascertain the actual location and it is as expected. Open Windows explorer and it finds "Message_Constants.h and it does not find "message_constants.h" Now I have changed all occurrences to use the leading caps version but this problem remains.
Why on earth are you editing those header files? It technically should not matter if headers use "message_constants.h" or "Message_Constants.h" unless you have modified the OS group policy that enforces case sensitivity[^]. File a bug if this is an issue for your organization. Learn to use the tools you are given. You should be using the /showIncludes (List Include Files)[^] option for debugging nested include bugs. How to: View, Save, and Configure Build Log Files[^] Enable 'Diagnostic' verbose logging. Search that log for message_constants.h and you should quickly find the offending file. Career Advice: You should always avoid #including headers from headers... from other nested headers. Yes, this means you may need to add
#include "your_header.h"in 50 different CPP files. Best Wishes, -David Delaune -
Hmmmm,
bkelly13 wrote:
While trying to chase down this problem I discovered that the file name is really Message_Constants.h. When I chase down the error the file name at the top of the edit windows shows the name "message_constants.h" It also shows "Message_Constants.h" What is with the all lower case versus the leading caps? I execute a Save As to ascertain the actual location and it is as expected. Open Windows explorer and it finds "Message_Constants.h and it does not find "message_constants.h" Now I have changed all occurrences to use the leading caps version but this problem remains.
Why on earth are you editing those header files? It technically should not matter if headers use "message_constants.h" or "Message_Constants.h" unless you have modified the OS group policy that enforces case sensitivity[^]. File a bug if this is an issue for your organization. Learn to use the tools you are given. You should be using the /showIncludes (List Include Files)[^] option for debugging nested include bugs. How to: View, Save, and Configure Build Log Files[^] Enable 'Diagnostic' verbose logging. Search that log for message_constants.h and you should quickly find the offending file. Career Advice: You should always avoid #including headers from headers... from other nested headers. Yes, this means you may need to add
#include "your_header.h"in 50 different CPP files. Best Wishes, -David DelauneThree people have posted and chewed me out for editing the Visual Studio files. Still, as I perceived this thread, the core problem has been ignored. I had a project that compiled an ran and started getting errors where it should not. Why might I get YesNoMaybe redefined? If the code that has that is prefixed with #pragma once, why might Visual Studio re-read that file that is knows is has already read, then declare the item redefined. The error appears, from my perspective, to be a failure of #pragma once to not do fulfill its intended purpose. I will be adding option /showIncludes and see if I can derive any information from that. Just as a side comment, these kinds of problems would probably be much easier to deal with if I could find anyone else around here that uses Visual Studio. Edit: I edited more information into my original post at the bottom.
Thank you for your time
-
Three people have posted and chewed me out for editing the Visual Studio files. Still, as I perceived this thread, the core problem has been ignored. I had a project that compiled an ran and started getting errors where it should not. Why might I get YesNoMaybe redefined? If the code that has that is prefixed with #pragma once, why might Visual Studio re-read that file that is knows is has already read, then declare the item redefined. The error appears, from my perspective, to be a failure of #pragma once to not do fulfill its intended purpose. I will be adding option /showIncludes and see if I can derive any information from that. Just as a side comment, these kinds of problems would probably be much easier to deal with if I could find anyone else around here that uses Visual Studio. Edit: I edited more information into my original post at the bottom.
Thank you for your time
Hi, Aren't you an experienced C/C++ software engineer? I have seen you on this forum for many years... how can you get this wrong? The answer you are looking for is located in your edited original message above:
bkelly13 wrote:
c:\program files\
**Microsoft visual studio 9.0**\vc\include\codeanalysis\sourceannotations.h(57): error c2011: 'vc_attributes::YesNoMaybe' : 'enum' type redefinition (indented here) c:\program files\**Microsoft visual studio 10.0**\vc\include\codeanalysis\sourceannotations.h(57) " see declaration of 'vc_attributes:: YesNoMaybe'Your project is pulling in the sourceannotations.h header from both VS2008 and VS2010. Fix your project #include paths. Best Wishes, -David Delaune
-
Three people have posted and chewed me out for editing the Visual Studio files. Still, as I perceived this thread, the core problem has been ignored. I had a project that compiled an ran and started getting errors where it should not. Why might I get YesNoMaybe redefined? If the code that has that is prefixed with #pragma once, why might Visual Studio re-read that file that is knows is has already read, then declare the item redefined. The error appears, from my perspective, to be a failure of #pragma once to not do fulfill its intended purpose. I will be adding option /showIncludes and see if I can derive any information from that. Just as a side comment, these kinds of problems would probably be much easier to deal with if I could find anyone else around here that uses Visual Studio. Edit: I edited more information into my original post at the bottom.
Thank you for your time
The problem is glaringly obvious it's telling you the problem You must have noticed the file path names... Microsoft visual studio 9 ... Microsoft visual studio 10.0 You either compile for VC9 or you Compile for VC10 what you can't do is mix and match the system files. That means either 1.) Your project file incorrectly references both sets of VC base directories ... a big no no 2.) Some header directly includes the VCx files from the other system. FIX IT .. CHOOSE 1 VERSION OF VC !!!!!!! There is a fast haxx way which is to rename one of the VC base directory trees temporarily ... the compiler can't use what it can't find :-) It will either fix everything that means your project file is DORKED or it will spit it can't find xyz file and that will be the wrong VC directory so fix it.
In vino veritas
-
Three people have posted and chewed me out for editing the Visual Studio files. Still, as I perceived this thread, the core problem has been ignored. I had a project that compiled an ran and started getting errors where it should not. Why might I get YesNoMaybe redefined? If the code that has that is prefixed with #pragma once, why might Visual Studio re-read that file that is knows is has already read, then declare the item redefined. The error appears, from my perspective, to be a failure of #pragma once to not do fulfill its intended purpose. I will be adding option /showIncludes and see if I can derive any information from that. Just as a side comment, these kinds of problems would probably be much easier to deal with if I could find anyone else around here that uses Visual Studio. Edit: I edited more information into my original post at the bottom.
Thank you for your time
bkelly13 wrote:
if I could find anyone else around here that uses Visual Studio.
Just about everyone who comes here uses Visual Studio on a daily basis. As stated by two other posters your project was in a mess, which was why you got that problem, but the information you originally provided did not show it up. In fact from your original question it was not possible to figure out what you were doing, hence my comments.
-
Hi, Aren't you an experienced C/C++ software engineer? I have seen you on this forum for many years... how can you get this wrong? The answer you are looking for is located in your edited original message above:
bkelly13 wrote:
c:\program files\
**Microsoft visual studio 9.0**\vc\include\codeanalysis\sourceannotations.h(57): error c2011: 'vc_attributes::YesNoMaybe' : 'enum' type redefinition (indented here) c:\program files\**Microsoft visual studio 10.0**\vc\include\codeanalysis\sourceannotations.h(57) " see declaration of 'vc_attributes:: YesNoMaybe'Your project is pulling in the sourceannotations.h header from both VS2008 and VS2010. Fix your project #include paths. Best Wishes, -David Delaune
David, Yes, I have been here for maybe 15 years. I have never had a good opportunity to work with anyone that knows Visual Studio itself well. I have written some rather good code, but have not and do not know how to use VS to its best advantage. Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term. On to this problem. Now that you guys have egged me on a bit, a very good thing, I discovered: Click on start, computer, properties, Advanced system settings, Environment Variables. Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib" I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved. Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today. I do thank each of you for the time you took to reply.
Thank you for your time
-
David, Yes, I have been here for maybe 15 years. I have never had a good opportunity to work with anyone that knows Visual Studio itself well. I have written some rather good code, but have not and do not know how to use VS to its best advantage. Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term. On to this problem. Now that you guys have egged me on a bit, a very good thing, I discovered: Click on start, computer, properties, Advanced system settings, Environment Variables. Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib" I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved. Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today. I do thank each of you for the time you took to reply.
Thank you for your time
bkelly13 wrote:
Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term.
I have no idea... I have not read a Visual Studio manual since ~1994 back when I was using Visual C++ 1.0. Here is a screenshot[^]. I keep it installed in a VM running Windows XP for nostalgic reasons. Unfortunately my technique for becoming a "Visual Studio Power User" is to spend 20+ years of my life in the IDE almost daily.. including many weekends.
bkelly13 wrote:
Now that you guys have egged me on a bit, a very good thing, I discovered: Click on start, computer, properties, Advanced system settings, Environment Variables. Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib" I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved.
I believe the older versions of Visual Studio had an option in the Installation Wizard to "Set Environment variables for LIB, INCLUDE and PATH" so that you could compile code from a command prompt. I would recommend removing them... you can always use the Visual Studio command prompt and allow \VC\bin\vcvars[*].bat to set the environment variables.
bkelly13 wrote:
Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today.
That one is located in the MFC source folder. \VC\atlmfc\src\mfc It is somewhat unusual that you need to pull this file into your project... it means that your project may be extending MFC functionality relating to OLE. Best Wishes, -David Delaune
-
bkelly13 wrote:
Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term.
I have no idea... I have not read a Visual Studio manual since ~1994 back when I was using Visual C++ 1.0. Here is a screenshot[^]. I keep it installed in a VM running Windows XP for nostalgic reasons. Unfortunately my technique for becoming a "Visual Studio Power User" is to spend 20+ years of my life in the IDE almost daily.. including many weekends.
bkelly13 wrote:
Now that you guys have egged me on a bit, a very good thing, I discovered: Click on start, computer, properties, Advanced system settings, Environment Variables. Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib" I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved.
I believe the older versions of Visual Studio had an option in the Installation Wizard to "Set Environment variables for LIB, INCLUDE and PATH" so that you could compile code from a command prompt. I would recommend removing them... you can always use the Visual Studio command prompt and allow \VC\bin\vcvars[*].bat to set the environment variables.
bkelly13 wrote:
Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today.
That one is located in the MFC source folder. \VC\atlmfc\src\mfc It is somewhat unusual that you need to pull this file into your project... it means that your project may be extending MFC functionality relating to OLE. Best Wishes, -David Delaune
David, Re:
Quote:
It is somewhat unusual that you need to pull this file into your project... it means that your project may be extending MFC functionality relating to OLE.
I am not intentionally doing anything with OLE. I can google and see that it means Object Linking and Embedding but in this app I barely use the user dialog. I did get rid of something and now when I capture the Output windows that file is no longer there. I now get a successful build. We are working on moving up to VS 2015 and having similar problems with it on another computer. Now is a good time to perform a bunch of searches and get rid of any detritus that has accumulated over the years.
Thank you for your time
-
David, Re:
Quote:
It is somewhat unusual that you need to pull this file into your project... it means that your project may be extending MFC functionality relating to OLE.
I am not intentionally doing anything with OLE. I can google and see that it means Object Linking and Embedding but in this app I barely use the user dialog. I did get rid of something and now when I capture the Output windows that file is no longer there. I now get a successful build. We are working on moving up to VS 2015 and having similar problems with it on another computer. Now is a good time to perform a bunch of searches and get rid of any detritus that has accumulated over the years.
Thank you for your time
There is no point going to VS2015 it's obsolete you need to go straight to VS2017. It will import and adjust most solution files automatically and is fairly reliable at it. It also has all the MFC code source files because MFC is no longer sold or directly supported by Microsoft as it has been replaced. VS2017 is also free for individual or small companies under it's community edition which is identical to the full product save it excludes direct support and the team workspace and code share options are disabled. The only time you now need earlier versions of VS is if you need to have code for Windows O/S earlier than XP. Every Windows O/S from XP onwards can be targetted by VS2017 as well as Android, iOS Mac, Unity3D, Linux Command line and some new ARM mobile phone stuff. I have uninstalled all my earlier versions of Visual Studio there is no situation I have found they are ever required.
In vino veritas
-
There is no point going to VS2015 it's obsolete you need to go straight to VS2017. It will import and adjust most solution files automatically and is fairly reliable at it. It also has all the MFC code source files because MFC is no longer sold or directly supported by Microsoft as it has been replaced. VS2017 is also free for individual or small companies under it's community edition which is identical to the full product save it excludes direct support and the team workspace and code share options are disabled. The only time you now need earlier versions of VS is if you need to have code for Windows O/S earlier than XP. Every Windows O/S from XP onwards can be targetted by VS2017 as well as Android, iOS Mac, Unity3D, Linux Command line and some new ARM mobile phone stuff. I have uninstalled all my earlier versions of Visual Studio there is no situation I have found they are ever required.
In vino veritas
leon de boer wrote:
MFC is no longer sold or directly supported by Microsoft as it has been replaced.
When did that happen?! :wtf: What replaced it?
The difficult we do right away... ...the impossible takes slightly longer.
-
leon de boer wrote:
MFC is no longer sold or directly supported by Microsoft as it has been replaced.
When did that happen?! :wtf: What replaced it?
The difficult we do right away... ...the impossible takes slightly longer.
.NET is Microsoft replacement framework if you open VS2015 or VS2017 it's everywhere in the templates at the top of the project settings. I quote from May Wang at Microsoft in 2015: "MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time." They then went on to release the sourcecode even in the free community edition of Visual Studio which was there equivalent of saying up to you to support it yourself going forward if you want to use it. That is pretty much by the book end of life cycle for software development :-)
In vino veritas
-
leon de boer wrote:
MFC is no longer sold or directly supported by Microsoft as it has been replaced.
When did that happen?! :wtf: What replaced it?
The difficult we do right away... ...the impossible takes slightly longer.
.NET is Microsoft replacement framework if you open VS2015 or VS2017 it's everywhere in the templates at the top of the project settings. I quote from May Wang at Microsoft in 2015: "MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time." They then went on to release the sourcecode even in the free community edition of Visual Studio which was there equivalent of saying up to you to support it yourself going forward if you want to use it. The code itself no longer has any commercial value to MS. That is pretty much by the book end of life cycle for software development :)
In vino veritas
-
.NET is Microsoft replacement framework if you open VS2015 or VS2017 it's everywhere in the templates at the top of the project settings. I quote from May Wang at Microsoft in 2015: "MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time." They then went on to release the sourcecode even in the free community edition of Visual Studio which was there equivalent of saying up to you to support it yourself going forward if you want to use it. The code itself no longer has any commercial value to MS. That is pretty much by the book end of life cycle for software development :)
In vino veritas
Thanks. I agree with what you've said, but what replaced it as far as building native desktop applications?
The difficult we do right away... ...the impossible takes slightly longer.
-
.NET is Microsoft replacement framework if you open VS2015 or VS2017 it's everywhere in the templates at the top of the project settings. I quote from May Wang at Microsoft in 2015: "MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time." They then went on to release the sourcecode even in the free community edition of Visual Studio which was there equivalent of saying up to you to support it yourself going forward if you want to use it. The code itself no longer has any commercial value to MS. That is pretty much by the book end of life cycle for software development :)
In vino veritas
Hi,
leon de boer wrote:
"MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time."
You can distribute your MFC or Win32 application in the Microsoft Store via the Desktop Bridge[^] Bring existing legacy apps and games to the Windows Store.[^] Best Wishes, -David Delaune
-
Thanks. I agree with what you've said, but what replaced it as far as building native desktop applications?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
I agree with what you've said, but what replaced it as far as building native desktop applications?
MFC is actively maintained for Desktop development. The latest version MFC 14.10.25008.0 was released back in March 2017. Of course everyone is encouraged to move towards adopting the modern Universal Windows Platform. Best Wishes, -David Delaune
-
Thanks. I agree with what you've said, but what replaced it as far as building native desktop applications?
The difficult we do right away... ...the impossible takes slightly longer.
If you mean what does Microsoft marketing want you to use to program desktop apps then the answer is C# with .Net that was the whole push with VS2017 you actually have to select to install C++ as an option with VS2017. I don't know how successful they were with it, there was considerable pushback at them over the C++ issue. As a fulltime commercial programmer I have always programmed on the Windows API so it all means little to me because I would never waste my time supporting any of the frameworks they all come and go. Once you have you own library sets there is little attraction in any of the framework groups. So I really want nothing more than a functional C++ compiler with a good IDE and debugger which VS2017 has in spades. I probably represent the problem for MS compiler marketing that they need to sell me something and there is very little I need from them :-) Anyhow here is the Desktop Marketing blurb for C++ from VS2017 make of it what you will (but notice it's an option not the default install as is MFC within that) Windows desktop development with C++ in Visual Studio | Visual C++ Team Blog[^] I suspect somewhere down the track customers like me will end up using just the IDE with a linked compiler module. MS has an interesting community IDE called confusingly Visual Studio Code Visual Studio Code - Code Editing. Redefined[^] MS finally added C++ to Visual Studio Code compiling options late last year but it has several drawbacks to VS2017. The intellisense on it is not as developed as VS2017 and the compiler technology is very different and the code produced is not as efficient as VS2017. It's also worth looking at the backdrop to the c++ compiler at MS which now stands apart from Visual Studio itself Rejuvenating the Microsoft C/C++ Compiler | Visual C++ Team Blog[^]
In vino veritas
-
Richard Andrew x64 wrote:
I agree with what you've said, but what replaced it as far as building native desktop applications?
MFC is actively maintained for Desktop development. The latest version MFC 14.10.25008.0 was released back in March 2017. Of course everyone is encouraged to move towards adopting the modern Universal Windows Platform. Best Wishes, -David Delaune
MFC14 is from VS2015 it only supports .Net 4.6 and later .NET 4.6.1 They patched a few dropdeads in it for the release of VS2017 so it supports .NET 4.6.2. The history is clearly covered in Wikipedia if you need to reference: Microsoft Foundation Class Library - Wikipedia[^] You will note the major revision revision number has not changed from VS2015 to VS2017 on those releases unlike earlier situation and that is a direct consequence of no further development. As we speak right now MFC is currently broken again under .NET 4.6.2 on Windows 10 after the anniversary update is applied and now .NET 4.7 has been released. It's been like that for months so lets see how long it takes them to fix and support 4.7 as an indication of the support for MFC. Note VS2017 auto updated and downloaded WPF changes so it was compatible with .4.7 basically two days after .NET 4.7 update was released and it made it into the advertising blurb (Announcing the .NET Framework 4.7 | .NET Blog[^])
In vino veritas
