dotnet CLI: Rename project and command sub-folders

[MiYanni]

Follow-up to: #47746

Summary

Originally, I was planning on doing these renames as separate PRs, but that will take forever to get merged. Instead, I've lumped together several renames into one. These are all high-level renames, and do not encompass individual file changes. That will be in another follow-up PR.

Changes

• No source code changes at all
• Renamed commands folder to Commands
  • To change folder casing, you need to rename it to something different (I did Cmds) and then changed it to Commands.
• Renamed command sub-folders (for sub-commands) to match the style of the command folders
  • For example, Reference/dotnet-reference-add became Reference/Add
  • Some sub-command folders already matched this but with incorrect casing. So, to change casing, needed a 2-commit process. For example, Workload/clean became Workload/CleanCmd which then became Workload/Clean.
• Renamed dotnet.csproj to Microsoft.DotNet.Cli.csproj
  • Matches the namespace, which is normal practice.
  • NOTE: Namespace alignment will be a completely different PR.
  • This change was reverted.
• Renamed dotnet folder to Microsoft.DotNet.Cli
  • Normal practice for the folder to match the project name.
  • This change was reverted.

Example

• Before (the first rename PR) and after (this PR)
  • src\Cli\dotnet\commands\dotnet-reference\dotnet-reference-add
  • src\Cli\Microsoft.DotNet.Cli\Commands\Reference\Add
  • src\Cli\dotnet\Commands\Reference\Add

Keep in mind that src\Cli is a "product domain" folder. Meaning, each folder within src is a different "product" in a mono-repo sense. That's how we've come to organize this repo.

Rationale

There will be other Microsoft.DotNet.Cli.XXXXX projects as I'm refactoring things, so I really need everything to be consistent here. We already have Microsoft.DotNet.Cli.Utils and everything for the Cli will be prefixed with Microsoft.DotNet.Cli. Again, namespaces will be aligned soon. There are other planned renamings, but those are more focused on an individual level, or things like the .resx files being all named the same thing, or all the test folder related stuff for the CLI. There's a lot of work to do here, so bear with me.

[Copilot]

Copilot reviewed 1314 out of 1318 changed files in this pull request and generated no comments.

Files not reviewed (4)

• TemplateEngine.slnf: Language not supported
• sdk.sln: Language not supported
• source-build.slnf: Language not supported
• src/BuiltInTools/dotnet-watch/dotnet-watch.csproj: Language not supported

[MiYanni]

Oh, I should also mention that any of the .csproj files I opened, I made the whitespace consistent and some of these files, like this one, have the xml header and this copyright comment, which is not necessary for non-source files. There are very rare situations that the xml header is needed, but none of these .csproj files needed it.

[KalleOlaviNiemitalo]

• Renamed dotnet.csproj to Microsoft.DotNet.Cli.csproj

  • Matches the namespace, which is normal practice.

The project name matching the assembly name is normal practice.

[MiYanni]

• Renamed dotnet.csproj to Microsoft.DotNet.Cli.csproj

  • Matches the namespace, which is normal practice.

The project name matching the assembly name is normal practice.

While that is true, there is the <AssemblyName> property so that you can have them be different. It isn't the right time yet to change something like that (if needed). But what I said is also true. They aren't mutually exclusive statements.

Edit: I'm generally following most of the rules from these design guidelines. Using Microsoft.DotNet.Cli relates to this rule here: https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-assemblies-and-dlls

When it comes to standards/conventions/style, there are always places to bend/stray from those. It isn't a rigid requirement. But as mentioned, there are many other changes coming down the road, so this currently is just a pothole on that path I'm trying to fill it for now.

[KalleOlaviNiemitalo]

If I'm searching for the project from which the dotnet executable is built, I feel it is easier to do find -iname dotnet.csproj than git grep -i -e '<AssemblyName>dotnet</AssemblyName>' "*.csproj".

[MiYanni]

If I'm searching for the project from which the dotnet executable is built, I feel it is easier to do find -iname dotnet.csproj than git grep -i -e '<AssemblyName>dotnet</AssemblyName>' "*.csproj".

That might not be produced by this project in particular, as I go through and do refactoring/feature additions. All this work is in-progress, but needs to be regularly committed as this space is worked on by multiple teams. But I need to do a lot of prep work like this before I can make bigger changes.

However, I will keep that feedback in mind as I scaffold things out. The project I end up having that is the dotnet CLI executable might just be a thin client using some other libraries I create.

[dsplaisted]

I wrote the following before reading the other comments, but basically I agree with Kalle about the dotnet project rename.

• Renamed dotnet.csproj to Microsoft.DotNet.Cli.csproj

  • Matches the namespace, which is normal practice.
  • NOTE: Namespace alignment will be a completely different PR.

• Renamed dotnet folder to Microsoft.DotNet.Cli

  • Normal practice for the folder to match the project name.

I would prefer to avoid these renames. AFAIK the convention is for the assembly name, the namespace, and the project name to all be the same. The assembly name here is dotnet (for dotnet.dll). If the assembly name and the namespace don't match, I think it makes more sense to name the project after the assembly name. I think that makes it easier to understand and to find the right project or output DLL.

[MiYanni]

I wrote the following before reading the other comments, but basically I agree with Kalle about the dotnet project rename.

• Renamed dotnet.csproj to Microsoft.DotNet.Cli.csproj

  • Matches the namespace, which is normal practice.
  • NOTE: Namespace alignment will be a completely different PR.

• Renamed dotnet folder to Microsoft.DotNet.Cli

  • Normal practice for the folder to match the project name.

I would prefer to avoid these renames. AFAIK the convention is for the assembly name, the namespace, and the project name to all be the same. The assembly name here is dotnet (for dotnet.dll). If the assembly name and the namespace don't match, I think it makes more sense to name the project after the assembly name. I think that makes it easier to understand and to find the right project or output DLL.

I mentioned this in our standup but I'll put it here publicly. A majority of our CLI code is in this folder. However, I do not foresee this folder being the folder that creates the dotnet.dll in the future. That will likely be a separate, lightweight project that would reference this project, which would produce Microsoft.DotNetl.Cli.dll. But I'm not ready for that change yet, nor am I committed to this design. I cannot commit to a design until I'm further along. However, I do want "the meat" of the CLI to be in a separate library. But that might be one or more libraries; I don't know yet.

Here, this PR is intended to align things so that I could, eventually, make a PR that removes <AssemblyName>dotnet</AssemblyName> from this project and creates a new dotnet.csproj that references Microsoft.DotNet.Cli project. That dotnet.csproj would likely have a namespace something like Microsoft.DotNet.Cli.Client (or something similar) that represents just the actual launcher of the CLI. Again, nothing set in stone here. I'm not at the design phase yet.

[Forgind]

That will likely be a separate, lightweight project that would reference this project, which would produce Microsoft.DotNetl.Cli.dll.

I feel the need to point out that as far as this concern:

If I'm searching for the project from which the dotnet executable is built, I feel it is easier to do find -iname dotnet.csproj than git grep -i -e 'dotnet' "*.csproj".

It's also harder to do find -iname dotnet.csproj then still have to figure out what that references than it is to just have dotnet.dll be the thing.

The other concern that I mentioned earlier about this being a git disaster is, I think, exemplified by the fact that this already has quite a number of "complicated" merge conflicts:

[MiYanni]

That will likely be a separate, lightweight project that would reference this project, which would produce Microsoft.DotNetl.Cli.dll.

I feel the need to point out that as far as this concern:

If I'm searching for the project from which the dotnet executable is built, I feel it is easier to do find -iname dotnet.csproj than git grep -i -e 'dotnet' "*.csproj".

It's also harder to do find -iname dotnet.csproj then still have to figure out what that references than it is to just have dotnet.dll be the thing.

The other concern that I mentioned earlier about this being a git disaster is, I think, exemplified by the fact that this already has quite a number of "complicated" merge conflicts:

That's very easy to resolve. I just copy-paste the files into the new location. That's all. The files have no changes in this PR.

Edit: Good news. Merging main into the branch had zero conflicts. GitHub was lying, as it sometimes does.

[nagilson]

Based on the team discussion, it seems like this PR can be merged if the assembly/folder name for dotnet.dll is retained, which you've applied above. I do appreciate the new folder names removing a lot of the redundant information.