dotnet / dotnet/project-system

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:)

Open
#9,536 3 comments 0 reactions 0 assignees View on GitHub
Feature-Debugging Triage-Investigate
Dominant language
C#
Stars
1k
Forks
415
PR merge metrics
No merged PRs in 30d

Description

## 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](https://github.com/user-attachments/files/17089074/VSNotPersistProfileBugExtension.zip)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.