If you still have to use C++ with MFC/ATL avoid updating Visual Studio
-
That is odd. I use both VS2017 and VS2019. I never share project files between them. Each version has its own project files and I always keep them in separate subdirectories named VS2017 and VS2019 which are at the same level as the Source. I recently migrated over to VS2017, about a month ago, and I always copied the 17 files to the 19 directory and loaded them up, adjusted the SDK level, and everything worked. I have not tried to share a project between versions because it never occurred to me that it could possibly work.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Well... at work I only have the 2017 and we want to do tests with .Net core so I had to install 2019 at home.
Rick York wrote:
I recently migrated over to VS2017, about a month ago, and I always copied the 17 files to the 19 directory and loaded them up, adjusted the SDK level, and everything worked.
Somewhen in the future we will have to port the BIG project to .Net core, and (AFAIK it is not expected that VS2017 will work with .Net Core) we will have to open all solutions in 2019 to compile them within the correct framework and with the target sdk. So I started now with just open and see what happens. And it "works" as expected... wrong :sigh: :doh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Well... at work I only have the 2017 and we want to do tests with .Net core so I had to install 2019 at home.
Rick York wrote:
I recently migrated over to VS2017, about a month ago, and I always copied the 17 files to the 19 directory and loaded them up, adjusted the SDK level, and everything worked.
Somewhen in the future we will have to port the BIG project to .Net core, and (AFAIK it is not expected that VS2017 will work with .Net Core) we will have to open all solutions in 2019 to compile them within the correct framework and with the target sdk. So I started now with just open and see what happens. And it "works" as expected... wrong :sigh: :doh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I am proud to say I am approximately 0% soy ... :-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I had problems with my PC at work and I got it reinstalled by the IT. I then reinstalled Visual Studio 2017, getting the newest version available v15.9.24 They have changed the way they work with precompiled files. You can't create MFC C++ console projects anymore. The "new project" wizard is different too (MFC full app still working though, but in the new way) At least you can still open old projects created previously, at home with the Visual Studio 2019 Community Edition it doesn't work anymore. I have already found several places speaking about the problem but so far 3 of the supposed solutions tried (installing v141 packages, changing the project options and manual addition of the missing files + references) and still not working :doh: :mad: :sigh: :sigh: . I will continue investigating / trying things.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
I never left MFC because I refused to, back then, to use interpreter, garbage-collecting Java or its knock-off, interpreter C#. I use the latest C++17/20 community compiler, VS2019, and for free. The IDE serves me well too and I can configure it to compile today on any platform and machine setup I want. Every few years I have to re-seat my programs, though, since their MFC under-pinnings do change over time, the pch.h being one of them. From my perspective, Microsoft's most brilliant move was to humbly throw C# onto the Github code dump, hire Herb Sutter, the C++ ISO committee chair, and change all its docs to C++ examples. The code I daily write with modern C++ in modern MFC connecting to ultra-modern MFC GUI libraries like BCGSoft's BCGControlBar GUI library, is becoming more and more ODR compliant and maintainable, and even elegant. Doggedly hanging onto past versions of past versions of your programs (not to mention OSes), as well as past IDE versions are, IMO, not taking advantage of the 1000s of paid developers improving them. And as for C++, I am eagerly waiting for C++20 with Modules and C++23's Networking so I revamp my many MFC projects and evolve away from problematic dllimport/dllexports and Winsock2 (C++23 Networking will look very much like Winsock2 is my guess). Will it take time to re-do my projects? Yes. But this is where technical-debt comes from: taking the easy way out until everything breaks. Herb Sutter said in one of his posts that there were ~200 papers addressing/modifying/correcting C++ features last year, up from ~125 the year before. There is no comparison in long-term robustness of a language supported by the world's voting body (ISO) to a company who is only beholden to its shareholders (think: Microsoft's C#). Of course, if you are writing programs that don't need to survive the test of time, then I guess interpreters will do. I don't have that option. 40 years ago, Bjarne Strustrup invented C with classes and transformed programming with his principles. 29 years ago, Microsoft went all in on C++ and produced MFC. In the past few years, Microsoft has elevated MFC back on top. Go Microsoft. Excellent use of your trillions of dollars. Now, back to my MFC programming, but I thought it was worth the time to describe the other side of views on MFC. Avoid updating VS is silly advice.
-
I never left MFC because I refused to, back then, to use interpreter, garbage-collecting Java or its knock-off, interpreter C#. I use the latest C++17/20 community compiler, VS2019, and for free. The IDE serves me well too and I can configure it to compile today on any platform and machine setup I want. Every few years I have to re-seat my programs, though, since their MFC under-pinnings do change over time, the pch.h being one of them. From my perspective, Microsoft's most brilliant move was to humbly throw C# onto the Github code dump, hire Herb Sutter, the C++ ISO committee chair, and change all its docs to C++ examples. The code I daily write with modern C++ in modern MFC connecting to ultra-modern MFC GUI libraries like BCGSoft's BCGControlBar GUI library, is becoming more and more ODR compliant and maintainable, and even elegant. Doggedly hanging onto past versions of past versions of your programs (not to mention OSes), as well as past IDE versions are, IMO, not taking advantage of the 1000s of paid developers improving them. And as for C++, I am eagerly waiting for C++20 with Modules and C++23's Networking so I revamp my many MFC projects and evolve away from problematic dllimport/dllexports and Winsock2 (C++23 Networking will look very much like Winsock2 is my guess). Will it take time to re-do my projects? Yes. But this is where technical-debt comes from: taking the easy way out until everything breaks. Herb Sutter said in one of his posts that there were ~200 papers addressing/modifying/correcting C++ features last year, up from ~125 the year before. There is no comparison in long-term robustness of a language supported by the world's voting body (ISO) to a company who is only beholden to its shareholders (think: Microsoft's C#). Of course, if you are writing programs that don't need to survive the test of time, then I guess interpreters will do. I don't have that option. 40 years ago, Bjarne Strustrup invented C with classes and transformed programming with his principles. 29 years ago, Microsoft went all in on C++ and produced MFC. In the past few years, Microsoft has elevated MFC back on top. Go Microsoft. Excellent use of your trillions of dollars. Now, back to my MFC programming, but I thought it was worth the time to describe the other side of views on MFC. Avoid updating VS is silly advice.
rtischer8277 wrote:
Avoid updating VS is silly advice.
Not if you don't have the time / mood to re-do all your work. I have given the "heads up" for the people to avoid surprises like mine. That from one day to the other... pam, you HAVE to. This way, the ones that want to keep it up to date as you (and actually me too) have the possibility to plan it. The ones that don't want to be forced to update... now they know, they have to stay in their current version.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I had problems with my PC at work and I got it reinstalled by the IT. I then reinstalled Visual Studio 2017, getting the newest version available v15.9.24 They have changed the way they work with precompiled files. You can't create MFC C++ console projects anymore. The "new project" wizard is different too (MFC full app still working though, but in the new way) At least you can still open old projects created previously, at home with the Visual Studio 2019 Community Edition it doesn't work anymore. I have already found several places speaking about the problem but so far 3 of the supposed solutions tried (installing v141 packages, changing the project options and manual addition of the missing files + references) and still not working :doh: :mad: :sigh: :sigh: . I will continue investigating / trying things.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
I hit this wall quite a while back. I'm frozen at VS2017 15.7.6 because the subsequent versions of VS2017 broke the compiler for some of our legacy projects. Any VS version newer than 15.7.6 will result in memory buffer overflows while compiling these projects. Granted, these particular projects use an excessive amount of shared memory storage and other likely non-optimal code practices, but the older compiler handles them just fine.
-
I had problems with my PC at work and I got it reinstalled by the IT. I then reinstalled Visual Studio 2017, getting the newest version available v15.9.24 They have changed the way they work with precompiled files. You can't create MFC C++ console projects anymore. The "new project" wizard is different too (MFC full app still working though, but in the new way) At least you can still open old projects created previously, at home with the Visual Studio 2019 Community Edition it doesn't work anymore. I have already found several places speaking about the problem but so far 3 of the supposed solutions tried (installing v141 packages, changing the project options and manual addition of the missing files + references) and still not working :doh: :mad: :sigh: :sigh: . I will continue investigating / trying things.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
So many people are so quick to jump on use of mfc... lol I have to use a variety of technologies at my job. We have a large project in MFC, several C# WPF apps, and then many many flavors of embedded applications, some bare metal, and some have OS's (linux, threadX, even GHS integrity). There are even some older 16 bit windows programs that customers STILL use which I refuse to work on... Anyhow, I can most definitely understand how people use MFC still... there is simply no time to convert everything. And if you are adding on to someone else's native project via DLL's, bringing in .NET will cause too many managed-unmanaged transitions and give you a slower end result. Back to your question. I have 2019 installed as well. I have no option for wizard creation of an MFC "console" project. But, I do have one for a Windows console project. I was able to pick this one, it created the project. I then went to project properties and picked "Use MFC" and then I added "#include ", and then I was able to use some MFC. Yes, I agree, it did not do everything for me, but it definitely wasn't that hard... I feel like maybe I had to do this before and they used to have an option for "include MFC headers" when you made a Windows SDK console project. Guess that is gone.
-
So many people are so quick to jump on use of mfc... lol I have to use a variety of technologies at my job. We have a large project in MFC, several C# WPF apps, and then many many flavors of embedded applications, some bare metal, and some have OS's (linux, threadX, even GHS integrity). There are even some older 16 bit windows programs that customers STILL use which I refuse to work on... Anyhow, I can most definitely understand how people use MFC still... there is simply no time to convert everything. And if you are adding on to someone else's native project via DLL's, bringing in .NET will cause too many managed-unmanaged transitions and give you a slower end result. Back to your question. I have 2019 installed as well. I have no option for wizard creation of an MFC "console" project. But, I do have one for a Windows console project. I was able to pick this one, it created the project. I then went to project properties and picked "Use MFC" and then I added "#include ", and then I was able to use some MFC. Yes, I agree, it did not do everything for me, but it definitely wasn't that hard... I feel like maybe I had to do this before and they used to have an option for "include MFC headers" when you made a Windows SDK console project. Guess that is gone.
DanM2 wrote:
So many people are so quick to jump on use of mfc... lol
Need to add functionality to a legacy project
DanM2 wrote:
Back to your question. I have 2019 installed as well. I have no option for wizard creation of an MFC "console" project. But, I do have one for a Windows console project. I was able to pick this one, it created the project. I then went to project properties and picked "Use MFC" and then I added "#include <afxwin.h>", and then I was able to use some MFC. Yes, I agree, it did not do everything for me, but it definitely wasn't that hard... I feel like maybe I had to do this before and they used to have an option for "include MFC headers" when you made a Windows SDK console project. Guess that is gone.
My biggest rant was not for the I can't create a project with MFC (although I hadn't found the "C++ Windows desktop wizard" yet). My biggest problem is that the old projects with #include "stdafx.h" won't compile now because the new standard is with #include "pch.h" and #include "framework.h". So far I have added the VC++ v141, I have edited project properties (but not the project file directly) and tried to add it manually... that didn't work. I have given up for a while, because I have started my tests in the new structure and want to finish them first.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Sorry to read you have to move to .Net. You have my condolences.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Rick York wrote:
Sorry to read you have to move to .Net. You have my condolences.
Very kind of you :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I had problems with my PC at work and I got it reinstalled by the IT. I then reinstalled Visual Studio 2017, getting the newest version available v15.9.24 They have changed the way they work with precompiled files. You can't create MFC C++ console projects anymore. The "new project" wizard is different too (MFC full app still working though, but in the new way) At least you can still open old projects created previously, at home with the Visual Studio 2019 Community Edition it doesn't work anymore. I have already found several places speaking about the problem but so far 3 of the supposed solutions tried (installing v141 packages, changing the project options and manual addition of the missing files + references) and still not working :doh: :mad: :sigh: :sigh: . I will continue investigating / trying things.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Stingray Studio is a mature (more than 20 years old) MFC extension library. In spite Microsoft changes Visual Studio all the way, we keep our product up and working for each version/subversion of Visual Studio. Also, we provide some solutions for integration with .NET. Stingray GUI Development Tools & Components | Rogue Wave[^]
-
I love steamed Soy beans when I go to my local Japanese restaurant! ;) Sadly, with the Covid Thing I haven't been able to go there lately :mad: :((
So far from being a millennial Voyager is closer to the Earth!
