Visual Studio 2022 Developer Profile GUID Not Consistent Across Reinstalls

[fgimian]

Windows Terminal version

1.22.11141.0

Windows build number

10.0.26100.0

Other Software

Microsoft Visual Studio Community 2022

Steps to reproduce

1. Perform a fresh installation of Windows and Visual Studio Community 2022
2. Notice the two newly added profiles to Windows Terminal "Developer Command Prompt for VS 2022" and "Developer PowerShell for VS 2022"
3. Backup your settings.json for Windows Terminal
4. Repeat step 1 and notice the GUIDs of the profiles have changed; using your backed up configuration from step 3 on the new installation will not allow you to open those profiles as the GUIDs seem to be tied to the current installation and change upon reinstallation

Note: It is likely that this may occur upon reinstalling Visual Studio on the same Windows install but I haven't yet tested that scenario.

Expected Behavior

I was expecting that it would be possible to backup and restore my Windows Terminal settings.json and have it work on a fresh installation of Windows with the Visual Studio 2022 profiles.

Actual Behavior

Instead, the original profiles won't work on the new installation as their respective GUIDs will have changed and appear to be tied to the Visual Studio installation, making the old GUIDs unusable. Worse still, I can't seem to find where those GUIDs are defined so that I can template out the configuration file and replace the GUIDs myself.

The current behaviour makes it more confusing and difficult to backup and restore your settings.json across Windows reinstalls.

[DHowett]

Ugh, you're totally right.

Thoughts from triage:

• We use the unique VS install ID when generating the GUID
• That ID being unique is important to VS -- you can have multiple copies of the same VS version installed
• Maybe we should use the path as input to the GUID generator rather than the install ID
• We would need a way to migrate old profiles (based on the ID slug) to the new GUIDs, though...

I'm gonna put this one on the backlog while we think about autogenerated profile migration.

Sorry, I know it's a bit of an annoying bug. It also has long-term implications on, say, DSC integration and config migration across machines.

[DHowett]

/cc @heaths

[heaths]

That's correct. The generated GUID at initial design time is a critical design feature and was never really designed to be referenced. In fact, given how the new setup engine enables multiple copies with different configurations to be installed, I'm not sure it makes sense to roam profiles unless you can be reasonably sure VS installs are sufficiently compatible. If both WT profiles and VS are managed by DSC, I suppose it makes sense, but you'd need a stable profile ID somehow.

Is it reasonable to assume that the CSIDL-resolved path of VS would be equivalent for DSC? Seems likely. Maybe the WT profile should be a GUID seeded from the installation root once you replace any known CSIDLs e.g., Program Files, with some variable token (in case they are different across machines which...to be safe). You could also MD5 hash it (same number of chars as a GUID) but MD5 is probably blocked on FIPS machines. That's what we used to do in WiX for stable component GUIDs. Now, last I knew, it SHA2 hashes them and only takes the first 128 bits (collisions possible but still unlikely).

[fgimian]

@DHowett Apologies to ping you on this, but I was curious to ask a few follow-up questions if I may:

• Is this still an issue with the upcoming Visual Studio 2026? I suspect it is.
• Is the algorithm used to generate the GUID from the installation ID something that you could share so I could template out my Windows Terminal settings file? I understand if this is not possible.

Thanks heaps in advance! Fotis

[heaths]

I was the architect of the VS setup engine and can best answer that. No, it hasn't changed. There's also no algorithm. As explained above, it was intentionally random to allow for multi-instancing - installing the same major version with or without different minor versions and in different configurations, so one could try out new features in a way that doesn't break team requirements. There's no algorithm. We just generate a new GUID.

Or are you talking about the proposal above to generate a GUID for Windows Terminal based on the CSIDL-resolved path?

[fgimian]

I was the architect of the VS setup engine and can best answer that. No, it hasn't changed. There's also no algorithm. As explained above, it was intentionally random to allow for multi-instancing - installing the same major version with or without different minor versions and in different configurations, so one could try out new features in a way that doesn't break team requirements. There's no algorithm. We just generate a new GUID.

Or are you talking about the proposal above to generate a GUID for Windows Terminal based on the CSIDL-resolved path?

Apologies if perhaps I wasn't clear. My understanding was that each GUID is somehow linked to a particular installation of Visual Studio (I had assumed it was based on the instanceId).

As an example, I just installed Visual Studio 2026 and my instance ID is c9103f8b and the related entries in my Windows Terminal configuration are as follows:

...
            {
                "guid": "{f4eb5997-70dd-576a-b56b-97fbf864955c}",
                "hidden": false,
                "name": "Developer Command Prompt for VS 18",
                "source": "Windows.Terminal.VisualStudio"
            },
            {
                "guid": "{a580c2a7-afe3-5706-b459-19c471faca39}",
                "hidden": false,
                "name": "Developer PowerShell for VS 18",
                "source": "Windows.Terminal.VisualStudio"
            }
...

What I'm attempting to understand is how Visual Studio knows that these two GUIDs relate to this particular instance ID. I had initially thought that there was some algorithm that uniquely turned the instance ID into the GUIDs but it seems I was mistaken.

Hope I'm making some sense 😄 Fotis