C2011 ‘vc_sttributes::YesNoMaybe’ “ ‘enum’ type redefinition RESOLVED
-
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
-
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, Just a Comment. I assume that you understand that each 'C' or 'CPP' File, gets compiled into One and only One '.obj' module. The Linker stitches all those 'Obj' modules together, to create an Exe or DLL, your Target. In doing so, your program needs to link with other libraries and DLL's already on the system. For Instance, your program uses the keyboard, and uses the mouse. You did not have to write the code inside your program to track the mouse movements, register the clicks, etc. That was already done by Microsoft, and comes as part of the Windows Package. Now, Microsoft wrote all that stuff, but, the compiler needs to know what is available from Microsoft, I.e.: the function and other specifications that the Windows API provides. These specifications are included in the System Headers. If you change these specifications to suit your own purpose, well, it Might work if you also 'Re Compiled Windows' If you mess with your system header files, you are actually telling your compiler that Windows works different than that it actually does. Your Compiler caught you out, and stopped you writing a disaster. #include files do not make your program larger, at most it slows down your compiler and linker
All Software Engineers should Learn and Train Machine and Assembly Language, so as to really Understand how a computer Works Bram van Kampen
