Epic: Introduce DotNet aliases (synonyms to DotNetCore aliases)

[augustoproiete]

Background

Cake has many DotNetCore*** aliases for executing dotnet such as DotNetCoreBuild, DotNetCoreTest, etc.

The Core part in the name exists for historical reasons when .NET Core was first introduced and lasted until v3.1.

With .NET 5, Microsoft dropped the "Core" from the name, and it's time we start working towards doing the same in Cake. i.e. DotNetCoreBuild becomes DotNetBuild, DotNetCoreTest becomes DotNetTest, etc.

Agreed Implementation Approach

Cake 2.0.0 - Introduce new DotNet aliases & mark DotNetCore aliases as obsolete

• Move implementation of DotNetCore*** aliases and settings to DotNet***
  • New DotNet*** aliases have their own DotNet***Settings
  • Forward DotNetCore*** to DotNet*** aliases
  • The DotNetCore***Settings should inherit from DotNet***Settings so that old code continues to compile
• Mark all DotNetCore*** aliases as obsolete
• (optional) Update website docs to redirect URLs to DotNetCore*** aliases to DotNet*** aliases

Cake 3.0.0 - Sunset DotNetCore aliases

• Remove all DotNetCore*** aliases from the codebase
• (If not done in 2.0.0) Update website docs to redirect URLs to DotNetCore*** aliases to DotNet*** aliases

---

		DotNetCore alias		DotNet alias / synonym
✅	#3523	DotNetCoreMSBuild	➡️	DotNetMSBuild
✅	#3542	DotNetCoreTool	➡️	DotNetTool
✅	#3543	DotNetCoreRun	➡️	DotNetRun
✅	#3544	DotNetCoreExecute	➡️	DotNetExecute
✅	#3545	DotNetCoreClean	➡️	DotNetClean
✅	#3546	DotNetCoreRestore	➡️	DotNetRestore
✅	#3547	DotNetCoreBuild	➡️	DotNetBuild
✅	#3548	DotNetCoreBuildServerShutdown	➡️	DotNetBuildServerShutdown
✅	#3549	DotNetCoreTest	➡️	DotNetTest
✅	#3550	DotNetCoreVSTest	➡️	DotNetVSTest
✅	#3551	DotNetCorePublish	➡️	DotNetPublish
✅	#3552	DotNetCorePack	➡️	DotNetPack
✅	#3553	DotNetCoreNuGetPush	➡️	DotNetNuGetPush
✅	#3554	DotNetCoreNuGetDelete	➡️	DotNetNuGetDelete
✅	#3555	DotNetCoreNuGetAddSource	➡️	DotNetNuGetAddSource
✅	#3639	DotNetCoreNuGetDisableSource	➡️	DotNetNuGetDisableSource
✅	#3640	DotNetCoreNuGetEnableSource	➡️	DotNetNuGetEnableSource
✅	#3641	DotNetCoreNuGetHasSource	➡️	DotNetNuGetHasSource
✅	#3642	DotNetCoreNuGetListSource	➡️	DotNetNuGetListSource
✅	#3643	DotNetCoreNuGetRemoveSource	➡️	DotNetNuGetRemoveSource
✅	#3644	DotNetCoreNuGetUpdateSource	➡️	DotNetNuGetUpdateSource

		DotNetCore alias setting		DotNet alias setting /synonym
✅	#3523	DotNetCoreMSBuildSettings	➡️	DotNetMSBuildSettings
✅	#3542	DotNetCoreToolSettings	➡️	DotNetToolSettings
✅	#3543	DotNetCoreRunSettings	➡️	DotNetRunSettings
✅	#3544	DotNetCoreExecuteSettings	➡️	DotNetExecuteSettings
✅	#3545	DotNetCoreCleanSettings	➡️	DotNetCleanSettings
✅	#3546	DotNetCoreRestoreSettings	➡️	DotNetRestoreSettings
✅	#3547	DotNetCoreBuildSettings	➡️	DotNetBuildSettings
✅	#3548	DotNetCoreBuildServerSettings	➡️	DotNetBuildServerShutdownSettings
✅	#3549	DotNetCoreTestSettings	➡️	DotNetTestSettings
✅	#3550	DotNetCoreVSTestSettings	➡️	DotNetVSTestSettings
✅	#3551	DotNetCorePublishSettings	➡️	DotNetPublishSettings
✅	#3552	DotNetCorePackSettings	➡️	DotNetPackSettings
✅	#3553	DotNetCoreNuGetPushSettings	➡️	DotNetNuGetPushSettings
✅	#3554	DotNetCoreNuGetDeleteSettings	➡️	DotNetNuGetDeleteSettings
✅	#3555	DotNetCoreNuGetSourceSettings	➡️	DotNetNuGetSourceSettings

---

DotNetCore aliases - https://cakebuild.net/dsl/dotnetcore/

[Marusyk]

@augustoproiete
I'm interested in creating PR for this. Could you assign it to me?
I've done something similar before #2658

[augustoproiete]

Hey @Marusyk Thanks for looking into this one!

This particular issue is a big one and I'd like to break it into smaller chunks to make PR reviews manageable otherwise we risk having a PR that is too large to review and it stays behind like some of the ones we have today where it's hard to find the time to properly look at it and test it.

Do you think you can take a first look at the code and suggest a few different steps to get there on the items for Cake v1.0?

We get those issues created and you can knock some PRs out of each of those (and we leave this big one open until Cake 3.0 is out).

Some questions that comes to mind:

• Does it make sense do a separate PR for each individual alias (e.g. 1 PR for DotNetCoreBuild, separate PR for DotNetCoreClean, etc.? Or do we need to group PRs in a different way? (e.g. Start with DotNetCoreTool, then DotNetCoreMSBuild, etc.)? Or something else?

• Should we create the new DotNet*** aliases first, using the old DotNetCore***Settings as a first step, and then move to using the settings as DotNet***Settings?

• Should we leave the tests exactly as they are for Cake v1.0 (knowing that the calls will be redirected, so if they pass, we're good)?

What do you think @Marusyk & @cake-build/cake-team?

[Marusyk]

Hi @augustoproiete
Sorry for the late response.

Does it make sense do a separate PR for each individual alias (e.g. 1 PR for DotNetCoreBuild, separate PR for DotNetCoreClean, etc.? Or do we need to group PRs in a different way? (e.g. Start with DotNetCoreTool, then DotNetCoreMSBuild, etc.)

• Yeah, I think it would be easier: for implementing and fore review.

Should we create the new DotNet*** aliases first, using the old DotNetCoreSettings as a first step, and then move to using the settings as DotNetSettings?

• Let's create the new DotNet*** from the beginning.

Should we leave the tests exactly as they are for Cake v1.0 (knowing that the calls will be redirected, so if they pass, we're good)?

• it is also looks ok (to avoid many duplication)