Visual Studio adds ID Guids to the slnx file

[aateeque]

Any changes Visual Studio makes to an slnx it ends up adding an Id attribute to each folder node in the XML. This is undesirable as slnx file should not have guids in it. An example:

<Solution>
  <Folder Name="/Libraries/" />
  <Folder Name="/Libraries/Http.Client/" Id="896cf6f3-3767-66cf-5770-2408359b919b">
    <File Path="src/Libraries/Http.Client/README.md" />
    <Project Path="src/Libraries/Http.Client/Client/Blaze.Libraries.Http.Client.csproj" />
    <Project Path="src/Libraries/Http.Client/Tests/Blaze.Libraries.Http.Client.Tests.csproj" />
  </Folder>
 </Solution>

There's a Id added to the Folder.

Instead this version without the Id works fine and looks and feels cleaner (one of the goals with moving away from the old sln format):

<Solution>
  <Folder Name="/Libraries/" />
  <Folder Name="/Libraries/Http.Client/">
    <File Path="src/Libraries/Http.Client/README.md" />
    <Project Path="src/Libraries/Http.Client/Client/Blaze.Libraries.Http.Client.csproj" />
    <Project Path="src/Libraries/Http.Client/Tests/Blaze.Libraries.Http.Client.Tests.csproj" />
  </Folder>
 </Solution>

This also can impact developer workflow with esoteric guids use in pull request.

[patrikwlund]

I have noticed the same issue. Tested for several different solutions in both VS 17.3.4 and in 17.4.0 Preview 2.0.

[markusschaber]

As the commit message for Frog-Gaming/meercat-monitor@a325d24 seems to indicate that one problem are changing UUIDs:

Resave slnx with a folder id so VS does not generate it as changes

If there's really a problem with regenerating different UUIDs on the fly each time the .slnx file is parsed, a possible solution might be to use name based UUIDs (aka Version 5), standardized in RFC 9562.

[patrikwlund]

As the commit message for Frog-Gaming/meercat-monitor@a325d24 seems to indicate that one problem are changing UUIDs:

The problem that @aateeque and I are referring to is the addition of the Id attribute at all. We don't want it there and it seems unnecessary. It seemingly doesn't actually use that ID for anything. It's not used for tree node references within the slnx file at all.

Here is what three nested directories with a file and a project at the deepest level looks like:

<Folder Name="/first/" Id="02ea681e-c7d8-13c7-8484-4ac65e1b71e8" />
<Folder Name="/first/second/" Id="5373a3ce-e871-4981-9781-766616b25fb7" />
<Folder Name="/first/second/third/" Id="9afe0a0e-3ef9-4cfe-94d3-cb257b6f1aca">
  <File Path="README.md" />
  <Project Path="ConsoleApp1/ConsoleApp1.csproj" Id="da119114-3c03-433c-8f35-f331e13cf1bc" />
</Folder>

All the folders have an Id but it is not referenced anywhere else in the file. Thus for persistence purposes it is just dead weight and unnecessary clutter. If some tooling wants an ID per node for internal referencing, then they can invent their own ID. Or this library can generate one on the fly for them. But don't persist it to the slnx when saving!

[asbjornu]

@patrikwlund What I understood from @markusschaber's comment is that if Visual Studio need stable UUIDs internally, it should use RFC 9562 to mint those UUIDs in-memory based on the folder names and not persist them to disk. I agree that one of the goals of a new solution files are (or at least should be) to not see UUIDs anywhere anymore.