File extension ".sln" is sometimes required and other times not

[Der-Kraken]

If you call dotnet new sln --name then the file extension ".sln" is added for you to the file. If you have the file extension in the shell option then ".sln" is written two times.

dotnet new sln --name mysolution
-> new Solution file named "mysolution.sln"

dotnet new sln --name mysolution.sln
-> new Solution file named "mysolution.sln.sln"

That alone is no problem but if you call then the command below it will be:

dotnet sln mysolution list
-> error: no solution file was found
  (I expected to get the solution I created with `dotnet new sln --name mysolution.sln`)

dotnet sln mysolution.sln list
-> A solution is found, but the wrong one 
  (I expected to get the solution I created with `dotnet new sln --name mysolution.sln.sln`)

dotnet sln mysolution.sln.sln list
-> A solution is found
  (I expected to get an error)

I think it should be one behavior in one tool. I call the command above in one script and I have a variable $solutionname. For each call of the command I muss add the file extension or not.

I don't think it would be a good idea to change this behavior because of existing scripts out there. But I would tell you the behavior if not already known.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[You-now-Who]

Can I work on this?

[Nirmal4G]

With .slnx coming down the line, it would be best to fix this in the early stage. I propose two paths here when the extension is not specified...

1. Add the extension (first .sln and then .slnx) to the input name and check if it exists in that order and proceed. If both solution files are present then disambiguate or warn or error out depending on the command context.
2. Error out and ask the user to provide the file extension since we have two types of solution files now.

@baronfel What do you think? I can take this along with the #40817.

[baronfel]

@Nirmal4G I think we should punt on the slnx concerns entirely for the scope of this issue (the duplicate-file scenario is covered as part of the new-slnx work in https://github.com/dotnet/sdk/issues/40913). I do think we should accept extension-less solution files in the sln commands as described above for consistency.

[Nirmal4G]

I know. I was asking about future proofing. I'm not going to put the code which does not work today. You'll see what I was talking about when I put the Draft PR.

So, Can I work on this?

[baronfel]

@Nirmal4G I think it's safe to go for it, thanks!