|
That kind of shortcut will open the default VS version. I have 8 of them, at least 3 in daily use, so I have to define the actual exe I want to open and the solution file is command line parameter...
So my shortcut is different...
Instead target being solution.sln it is path-to-vs-2020-exe solution.sln
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
And that is why you should always include accurate steps to reproduce when discussing bugs. Everything else just wasting time as there are too many options.
Updated steps to reproduce:
1) Search for Visual Studio in the Windows search menu
2) Right click "Visual Studio 2022" in "Apps"
3) Select "Open file location"
4) When Explorer opens, copy the selected shortcut to a new location (I use the desktop)
5) Right click the shortcut and select "Properties"
6) Locate a solution (*.sln file)
7) Right click the solution and select "Copy as path". On Windows 10, you need to hold shift when right clicking
8) In the properties for your shortcut opened in step 5, click the "Target" text box
9) Press "End" on the keyboard (this will take the cursor to the end of the text)
10) type a space, then paste from the clipboard. This will add the solution path to the shortcut.
11) Click OK to close the properties
12) Double-click your shortcut copy to start Visual Studio
Expected result:
Visual Studio opens and loads the solution without errors
Observed result:
Visual Studio opens and loads the solution without errors
|
|
|
|
|
Yep - that kind of shortcut...
Now I tried from scratch both kind - it opens only once without error (the first try) and than fails with the very same error...
Are you on W10 or W11?
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
W11 - and no problem opening it multiple times.
From what I could google, that error is likely to be driver related. I assume you already checked you have the latest drivers installed.
|
|
|
|
|
It is the same driver for VS2019 and VS2022...
According to the event log it is about WPF somehow...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
VS2022 and VS2019 will not send 100% identical commands with 100% identical data with 100% the same timing to the driver. So one program running fine while the other doesn't will not clear the driver of any wrongdoing. And since it is WPF that runs the UI in VS, it will look like it is "about WPF somehow" if your driver is doing the wrong thing.
But just to be double clear: I did NOT - repeat - NOT - write "this is a driver issue". I googled the error. Read a few links. Driver issues where mentioned. Basic on the information available I can't say if the error is in the driver, the Windows graphics layer, WPF, or Visual Studio. But you can't either, so you should not conclude "VS2022 is broken" due to this.
One hint though: If you have MSI Afterburner installed, try uninstalling it. It injects itself into the driver, and it has killed my rather simple WPF based program before.
|
|
|
|
|
Try re-creating your shortcuts. At least one to test. I have a project that I only want to open in VS2019. I created a shortcut to devenv.exe (2019 version) and passed in the sln. It worked fine.
I have another project started in 2019 but I created a shortcut to devenv.exe (2022 version) and it also worked fine.
So my best guess is to try recreating your shortcut to see what happens.
Ron
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
The only error I've found so far in VS2022 is to do with text transformation on build. It works in VS2019, but crashes in VS2022... I've asked about this on StackOverflow but if I don't get an answer will also ask Microsoft.
Of course, I use several extensions and one minor annoyance is that either CodeMaid or Resharper (haven't tried to identify which yet) keeps wanting to change some of my namespaces to file scoped when I try to clean it up.
namespape xxx
{
....
}becomes
namespace xxx;
.... which, of course, breaks the code for VS2019!
There's probably a switch to turn it off if I had time to find it...
|
|
|
|
|
I am waiting for a few updates to by before I upgrade form VS 2019...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I like to obsessively check if there is any windows update...
And you know what? I got new Windows update 3 times since yesterday (when I installed Windows 11)! 
|
|
|
|
|
Did any of those updates restore the 'start' button? I am in the 'dark humor' mood.
Nick Polyak
|
|
|
|
|
What do you think?
You are right!
(I am a precog mind reader)
modified 16-Dec-21 8:46am.
|
|
|
|
|
So, I have this ancient VC6++ project. A very simple application that someone else wrote long ago. I want to convert it to VS2019. True to form, VS2019 alerts me that "this project is in an older format, it will need to be converted." I press okay. It converts. And it won't compile.
Enter precompiler directive hell...
As I'm plowing through all of my google searches, it occurs to me that I have *never* had a project convert and then compile. I would think that the clowns in Redmond would have figured this out by now. But noooo, this apparently has not occurred to them.
I have other rants for the west coast clowns, but I'll get my coat.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
You will be lucky if it fully complies to a version of the standard. If it is written in one of those "pre-alpha maybe it will be part of the standard" versions, adding to your "precompiler directive hell" comment, you have a potential nightmare project on your hands
And if you are running low on luck, it is written using a GUI library that is no longer maintained for ages 
Good luck and remember "it can not rain forever" 
|
|
|
|
|
It's very plain C++ and mfc, hence my rant.
I'm about to do a test. I'm going to create a Hello Clowns app - simple dialog nothing else but default clown code. I'll do it in VS2008, as VS6 is just asking too much. I'll pull it into 2019.
Anyone want to give me odds this isn't going to go well?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: Anyone want to give me odds
I don't even know how to guess those. I never used MFC. The only time (some 20 years ago) I had to do an application for Windows with a GUI, I used Borland C++ builder and their framework (can not recall the name).
Pardon my sarcasm but, I am sure Microsoft never released a version of MFC that was half baked and would brake functionality, turning a "plain" code into something not so simple.
So, how did the clowns behaved? Did they laughed with  or at  ?
|
|
|
|
|
I've done MFC twice in my life. Once as a student in VS6. And once professionally when to burn money left at the end of a contract - the (govt) customer didn't want the money back because it'd screw up their accounting - where I put a ribbon of lipstick on a pig so old it's port from C/Solaris to C with MFC gui (no actual C++ features were used) was done in VS97. I don't recall any issues getting the project running in VS2013.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
|
But it did stop... didn't it?! I don't go outside much these days 
Thank you for the interesting video. It made me smile the way he said it lasted a small period... of 2 million years.
|
|
|
|
|
Glad I could help.
I am sure you go out more than once in 2 million years!
|
|
|
|
|
I wouldn't know. I don't have enough fingers to count that high 
|
|
|
|
|
Fingers n toes. Then all you need is something to serve as bit 21.. 
|
|
|
|
|
Probably part of the reason is their compiler has gone through quite an evolution since then. I don't even think it's the same codebase - as in it has been rewritten at least once.
It used to be their compiler wasn't standard enough to implement the STL properly. That was in the bad old days of 6.
So bet on having to change your code in places. It's no so easy for an automagic tool to rewrite C++.
Real programmers use butterflies
|
|
|
|
|
That's because you're trying to convert a project written by a 1998 tool with a 2018 one. Precompiled headers management changed (luckily, as it was plain dumb in VC6) and mostly the standard changed, I had to add many casts when using floor and ceil because they are handled differently, otherwise it faild compilation.
Who knows if a project written for GCC 2.8.1 compiles with GCC 11.2 (and the accompanying libc versions).
Converting code is never, ever a click-boom task.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: Converting code is never, ever a click-boom task.
Good choice of words here. It probably does go "boom" in this case...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
