|
I haven't had any issues with opening solutions directly through my pinned solutions in the taskbar context menu.
No clue what's going on with OP's issue, though.
|
|
|
|
|
I dunno, I open pinned recent solutions on the taskbar button, and it open my project straight away fine.
I am not sure if it's the same thing as your special shortcuts, but that's what I do!....
Furthermore, at work our solution has, ahem, 600 projects, I just can't work with VS2019, but VS2022 works a treat!
|
|
|
|
|
I do not know how pinned solution different from a classic shortcut...
I have a mac-like toolbar that pops up when I hit the top side of the screen with the mouse. It holds classic shortcuts... Up until VS2019 had no problem with it...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Can I recommend you hard code a fresh new shortcut on the desktop.
And open that. See if that works.
Then apply that tweak to the shortcuts you are using.
Also, do the shortcuts for the OLDER versions STILL function properly?
|
|
|
|
|
It works only once...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Ah, 2 more questions.
1) If you reboot, does it work the first time again?
2) Create another fresh link. Then create 2 COPIES OF IT!
Now try the fresh shortcut. Twice. Confirm the failure
Then try one of the copies (only one)
Does it work? (I assume not)
If it does. compare the 2nd Copy to the first copy and see if the shortcut was modified.
It probably was NOT.
Next whatever EXE is being run. Go to task manager (after using the first link, the first time,
exit VS) and use task manager to KILL any processes linked to the shortcut.
Then... see if it works after that. (it shouldn't, since it is the second try).
My assumption. The program is not starting up, and is not forwarding on the shortcut parameters.
It is already running, and somehow ignoring the parameters!
|
|
|
|
|
Unable to reproduce
Environment: Visual Studio 2022 version 17.0.3, Windows 11 21H2
Steps to reproduce:
1) Drag an existing solution to the desktop using the right mouse button.
2) Select "Create shortcut here" in the popup menu
3) Double click the created shortcut
Expected behavior:
Visual Studio opens and load the solution without errors
Observed behavior:
Visual Studio opens and load the solution without errors
|
|
|
|
|
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
|
|
|
|
|