If a non-persistent launch profile is the last debug profile used, it will visually be selected on reopening the solution but that will be a lie:)

[mitchcapper]

Visual Studio Version

Microsoft Visual Studio Enterprise 2022 (64-bit) - Preview
Version 17.12.0 Preview 2.0

but this has happened for quite some time, I only now had a chance to track down why my launches were often broken when opening a project. I would say probably over a year, my guess is likely since IPersistOption came into existance.

Summary

This bug sadly took me far too long to track down due to the somewhat nasty way it presents.

If you are using a non-persistent profile and visual studio csproj.user file has that profiles name as the ActiveDebugProfile, visual studio will automatically set that to the active profile whenever it is created (ie even if way delayed after load, or in reaction to a button push from the user).

The problem is, it doesn't. It shows it as the active in the drop down menu, you can go to properties see it there as well, but its not active. Instead whatever the profile active before it, is still the active profile. The only way to make it the active profile is to switch off it and switch back onto it.

I have attached a small VS extension that reproduces this effect. After the extension is installed load any multi-launch style project. You will see "VirutalGenProfile" in the possible launch profiles after the solution has fully loaded. Go ahead and launch it, the executable launched will be launched with the command line args -our -random -args. Note this profile is set to not persist.

Now close visual studio out (sorry didn't properly seem to hook the project load), this will save "VirutalGenProfile" as the default profile. Reopen the vs again, after it loads and VirutalGenProfile is created it will automatically be set active. Start debugging and you will notice the command line args will not be the above.

There is a fix, by manually calling SetActiveProfile to ourselves it truly changes to us and is fixed. Granted we would need to detect if we are automatically switched to or not , which I guess would likely just involve reading the ActiveDebugProfile from the user vs config (as calling ActiveProfile will return the actual active profile not our virtual one).

You can do some other testing with the extension, setting FORCE_ACTIVE_PROFILE_WHEN_CREATING to true will set us as active and fixes it.

WAIT_TIME_BEFORE_PROFILE_CREATE to say 10 seconds will cause the profile to not be created for 10 seconds after load. This is to emulate say the profile being created in reaction to a user hitting a button without me actually adding a button. You will see even with the delay the profile still gets set to active if it is set as ActiveDebugProfile on the csproj.user file (although not work of course).

You can manually edit the csproj.user file to have any other name for the ActiveDebugProfile and it will also fix it, as it will not due its auto-switch.

Sample extension: VSNotPersistProfileBugExtension.zip

[mitchcapper]

While not the same issue this seems to be another example of the toolbar showing a launch profile that is not the actually selected launch profile:
#2967

Given launchSettingsProvider.ActiveProfile represents the true launch profile it would seem finding a way to grab the toolbar combobox value and comparing it would be an easy way to figure out is if it invalid.