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

[kasperk81]

Suggested change

	foreach (var buildType in new List<string> { "Debug", "Release" })
	foreach (var buildType in (string[])["Debug", "Release"])

[kasperk81]

that will hopefully fix errors like
System.Exception : Test dir /private/tmp/helix/working/BD4A0AC6/w/9AEF084D/e/testExecutionDirectory/WhenInvalidSo---41AFE22E_2 already exists

[edvilme]

Here, const strings for expected sln results were moved to a folder under TestAssets, with their .slnx counterparts generated by dotnet sln migrate.
Additional test cases were created for sln.
SlnFile was removed from these tests as well

[kasperk81]

the identifier doesn't help because testmanager's GetTestDestinationDirectoryPath shortens the directory name to 24 characters and we end up having the same errors.

short-term solution is #45130 which goes beyond _2 in the ci.

long-term solution is to make GetTestDestinationDirectoryPath stateless and use Path.GetTempFileName without any hashing or ci specific complexity; right now there are tests like GivenThatWeWantToVerifyNuGetReferenceCompat.Nuget_reference_compat which end up calling GetTestDestinationDirectoryPath multiple times during a single test run and expects names to be deterministic. it is fragile as is because in ci case, it also checks if the directory exists and start using _1 and _2 suffix so the second time it will be called it will get one of those suffixes. so it's at the verge of breakage as we can see in this pr. making sure that name is generated no more than once per test and using that name will make it stateless.

[edvilme]

the identifier doesn't help because testmanager's GetTestDestinationDirectoryPath shortens the directory name to 24 characters and we end up having the same errors.

Yes, it pushed before I was able to see your pr, bit of a sync issue there... I like the idea on your PR as it allows us to have a greater variety of different names for different cases (of which there are many on this pr)

[kasperk81]

getting closer! 👍

these tests are failing:

sdk/test/dotnet-new.Tests/PostActionTests.cs

Line 782 in e524077

public void AddProjectToSolution_BasicInSolutionRoot()

sdk/test/dotnet-new.Tests/PostActionTests.cs

Line 818 in e524077

public void AddProjectToSolution_WithOutputAbsolutePath()

sdk/test/dotnet-new.Tests/PostActionTests.cs

Line 854 in e524077

public void AddProjectToSolution_WithOutputRelativePath()

Expected command to not output to stderr but it was not:  
File Name: /Users/runner/work/1/s/artifacts/bin/redist/Release/dotnet/dotnet  
Arguments: new TestAssets.PostActions.AddProjectToSolution.Basic -n MyProject -o output --debug:custom-hive /Users/runner/work/1/s/artifacts/tmp/Release/dotnet-new.IntegrationTests/AddProjectToSolution_WithOutputRelativePath/Home/20241126201252329  
Exit Code: 0  
StdOut:  
The template "TestAssets.PostActions.AddProjectToSolution.Basic" was created successfully.  

Processing post-creation actions...  
Adding  
    project(s): /Users/runner/work/1/s/artifacts/tmp/Release/dotnet-new.IntegrationTests/AddProjectToSolution_WithOutputRelativePath/20241126201252329/output/MyProject.csproj  
    to solution file: /Users/runner/work/1/s/artifacts/tmp/Release/dotnet-new.IntegrationTests/AddProjectToSolution_WithOutputRelativePath/20241126201252329/output/MySolution.sln  
    solution folder: src  
Successfully added project(s) to a solution file.  

StdErr:  
Invalid project /Users/runner/work/1/s/artifacts/tmp/Release/dotnet-new.IntegrationTests/AddProjectToSolution_WithOutputRelativePath/20241126201252329/output/MyProject.csproj. The project file could not be loaded. Could not find file '/Users/runner/work/1/s/artifacts/tmp/Release/dotnet-new.IntegrationTests/AddProjectToSolution_WithOutputRelativePath/20241126201252329/MyProject.csproj'.  /Users/runner/work/1/s/artifacts/tmp/Release/dotnet-new.IntegrationTests/AddProjectToSolution_WithOutputRelativePath/20241126201252329/MyProject.csproj.

test is adding 20241126201252329/output/MyProject.csproj to sln and expecting 20241126201252329/MyProject.csproj (without the /output part)

[edvilme]

getting closer! 👍

these tests are failing:

Hii, thanks and thanks for your input. Yes, those tests are currently failing on several PRs and should be unrelated to the changes here. When they're fixed, I will update the branch :)

[kasperk81]

those tests are currently failing on several PRs and should be unrelated to the changes here

can you point me to it?
pr:

git checkout edvilme-slnx-add
./build.sh
.dotnet/dotnet test test/dotnet-new.Tests --filter 'AddProjectToSolution_BasicInSolutionRoot|AddProjectToSolution_WithOutputAbsolutePath|AddProjectToSolution_WithOutputRelativePath' 

Test summary: total: 3, failed: 3, succeeded: 0, skipped: 0, duration: 5,1s

main:

git checkout main
./build.sh
.dotnet/dotnet test test/dotnet-new.Tests --filter 'AddProjectToSolution_BasicInSolutionRoot|AddProjectToSolution_WithOutputAbsolutePath|AddProjectToSolution_WithOutputRelativePath' 

Test summary: total: 3, failed: 0, succeeded: 3, skipped: 0, duration: 6,4s

with 5 retries back and forth, those three tests 100% of the times fail with your branch locally and pass with main

[edvilme]

You're right. There were some other tests from templating failing, so I got them mixed up. The issue here is when adding projects from a different directory, e.g., dotnet sln subdirectory/App.sln add subdirectory/Project.csproj. I will look into that

[kasperk81]

lgtm (one nit)

[kasperk81]

this file only has whitespace change git checkout upstream/main :/Directory.Packages.props