sln-add: Support for slnx

[edvilme]

Contributes to #40913

The dotnet CLI should support the new slnx format for building and in the existing solution management commands. It should also help interested users migrate to the new format.

This adds dotnet sln add support for .slnx files

[kasperk81]

@edvilme checkout the complete feedback. using solution.FindProject makes the regex usage irrelevant

[edvilme]

Turns out the heuristics for generating project GUIDs are different between the old and new serializers, which was causing several tests to break. Replacing them should have no repercussions as they are mostly for identifying the projects individually

[kasperk81]

running dotnet sln add foo.weirdproj currently results in:

• project 'foo.weirdproj' has an unknown project type and cannot be added to the solution file. contact your sdk provider for support. — when the xml is valid
• invalid project 'foo.weirdproj'. the project file could not be loaded. data at the root level is invalid. line 1, position 1. — when the xml is invalid

the second error reflects validation behavior that goes against the single responsibility principle, as dotnet sln add shouldn’t be responsible for project file validation (unlike dotnet build).

tests conforming to SlnFile behavior (that passing an explicit unknown guid should succeed) have no user-facing meaning because, fortunately, there is no guid argument in the dotnet sln add command. removing these tests and related special error handling would simplify the code.

if tools like vs, vscode, slngen, and the sdk are transitioning to vs-solutionpersistence, there’s no reason to retain the discontinued monodevelop's SlnFile behavior.

these are all the “error” cases blocking this pr for two weeks, but none of them are actually relied upon for functionality. a note in the 9.0.2x docs like “we've switched to a new solution file library from the core vs team, replacing the old one from the discontinued monodevelop” should suffice to explain minor (git-diff visible) differences without impacting functionality.

[nagilson]

running dotnet sln add foo.weirdproj currently results in:

• project 'foo.weirdproj' has an unknown project type and cannot be added to the solution file. contact your sdk provider for support. — when the xml is valid
• invalid project 'foo.weirdproj'. the project file could not be loaded. data at the root level is invalid. line 1, position 1. — when the xml is invalid

the second error reflects validation behavior that goes against the single responsibility principle, as dotnet sln add shouldn’t be responsible for project file validation (unlike dotnet build).

tests conforming to SlnFile behavior (that passing an explicit unknown guid should succeed) have no user-facing meaning because, fortunately, there is no guid argument in the dotnet sln add command. removing these tests and related special error handling would simplify the code.

if tools like vs, vscode, slngen, and the sdk are transitioning to vs-solutionpersistence, there’s no reason to retain the discontinued monodevelop's SlnFile behavior.

these are all the “error” cases blocking this pr for two weeks, but none of them are actually relied upon for functionality. a note in the 9.0.2x docs like “we've switched to a new solution file library from the core vs team, replacing the old one from the discontinued monodevelop” should suffice to explain minor (git-diff visible) differences without impacting functionality.

I think you raise good points. @edvilme chatted with me regarding this, and we think we can remove these error cases blocking this PR. We are also going to go over these error cases with the SLNX team to make sure that none of these old behaviors are behaviors they deem to be important to keep.