Cake: Integrate Cake as a dotnet CLI extension for .NET Core applications

[amoerie]

I couldn't find if this has been suggested before, but I was looking at FlubuCore and how they integrate nicely with the dotnet CLI.

It struck me that this might be a perfect fit for cake too. I mean, wouldn't it be nice to do the following:

1. Restore regular NuGet packages _and_ Cake with its addins
   dotnet restore

1. Run the do-the-thing task that you would normally call with build.ps1 -Target "do-the-thing"
dotnet cake do-the-thing

I'm currently using Cake on a few projects here at work, and it's great! This sort of integration would make it even better though. 👍

[maximpashuk]

@devlead Can you give your opinion on this issue?

I read the articles
https://docs.microsoft.com/en-us/dotnet/core/tools/extensibility
https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package#setting-a-package-type

It says that to implement Cake.CoreClr as dotnet cli tool you should make 2 things:

1. Cake.dll should be renamed as dotnet-cake.dll to conform a convention (nuget package name can be the same as now).
2. Add <PackageType>DotnetCliTool</PackageType> in csproj.

Also dotnet cli repository
https://github.com/dotnet/cli/tree/master/TestAssets/TestPackages
contains some examples of cli tools.

Any plans to make Cake.CoreClr as cli tool?

[patriksvensson]

@maximpashuk Thanks for your feedback. Currently we got no plans to add a CLI tool for Cake.

[JonCubed]

@patriksvensson would you consider community contributions for this?

[adamhathcock]

I’m not sure what benefit an extension would be. Since installing a tool requires a project file, bootstrapping is awkward.

If they had a story that allows dotnet tools to be installed outside of a project then it might be useful, imo.

[JonCubed]

@adamhathcock you can have path based tools so it can be use across multiple solutions.

I can see it as a benefit to having it integrate into the tool chain that .net core users are already using and removing the need for the bootstrap script. I'm not doing anything funky with my bootstrap but perhaps for those that are having extensiblity hooks will be enough.

[amoerie]

That would mean every project you ever want to build on a machine has to share the same cake version though, which is unacceptable for CI build agents.

Coming from MSBuild, we had a global project wide packages.config file that referenced MSBuild extension packages hosted on NuGet. We also had a build.proj file that contained our project wide tasks.

The build.proj file has been replaced with build.cake, so maybe we can make a packages.csproj file that is only used for references to Cake? That would allow for repository specific Cake versions, just like now.

[adamhathcock]

well, I can see an advantage being you bootstrapper to install the tool then just use the dotnet tool CLI instead of a bootstrap script. It's not a huge one though.

doing dotnet cake run <target> just seems neat.

I definitely agree you generally don't want to install Cake system wide because of versions in CI.

[JonCubed]

@amoerie I don't believe that would be the case as tooling supports other methods like per-project and custom msbuild targets, it seems flexible enough for the various needs that will pop up.

I could see it working similar to npm packages where some are installed globally so you can init projects, modify files and be usable by editors, but each project then adds it so the version is pinned.

Global installs could also make sense when using containers as your agents.

[amoerie]

Ah yes as long as system wide is not the default "officially encouraged" option I agree that it can be useful for certain people. Imho, the recommended approach should be repository-specific Cake versions.

I believe the biggest benefit of implementing this would be lowering the barrier of entry for Cake. Playing nice with the dotnet CLI would also be a gesture of maturity and good will I believe.

Finally, getting rid of the powershell script would be a bonus too, it's a bit unfortunate that this has to be copy pasted in every repository just to bootstrap the build system.

[adamhathcock]

I don't think you can avoid a script for installation unless you somehow have a base project with the tool configured. Tools aren't at a solution level and there's no way to install them local to a repository without a project.

I've used a bootstrap project with some generated XML which could be a tool reference instead of a package reference.

[phillipsj]

So I have started doing exactly this: https://github.com/phillipsj/dotnet-cake

I think it would be easier to just

nuget install dotnet-cake

The run the command like above

```
dotnet cake build -Target
````
I have slowed down on it, but with the recent talk of bringing more of the bootstrapper into Cake itself, this is going to be a little simpler.

[andycmaj]

I don't think you can avoid a script for installation unless you somehow have a base project with the tool configured. Tools aren't at a solution level and there's no way to install them local to a repository without a project.

sounds like it would be appropriate for this to be a dotnet core global tool

[phillipsj]

Andy,

I have been working on one of these and I was waiting for a few changes to
make it into Cake before I finished it. I am going to refocus on my
efforts now that nuget is integrated.
https://github.com/phillipsj/dotnet-cake

On Tue, Feb 6, 2018 at 2:40 PM, andy cunningham [e-mail]
wrote:

sounds like it would be appropriate for this to be a dotnet core global
tool http://www.natemcmaster.com/blog/2018/02/02/dotnet-global-tool/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cake-build/cake/issues/1644#issuecomment-363540940,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfthV86QtlQV2cZKWqxC6CVZdWCmtN2ks5tSKrJgaJpZM4N5j50
.

[adamhathcock]

Cake as a global tool is something I definitely want. Should be doable after the Net core 2 stuff is merged.

[amoerie]

I see this thread is still going strong. While I'm advocating for nor against this CLI tool issue, we decided to continue with Cake Frosting.

The gist of this is that it removes the need for build.cake files, and instead makes you write your build logic as a console application that can be part of your solution. This has two big benefits:

1. Running your build is as easy as "dotnet publish your-build-app && your-build-app.exe". We still use a build.ps1 to file to ensure nuget is installed, the dotnet CLI is installed, etc.

2. Intellisense and debugging! Even though there is an excellent extension for VS Code now, it still cannot beat full fledged IDEs such as Visual Studio or Rider. With Cake.Frosting, your Cake targets are just C# classes that inherit from FrostingTask, and it's just another program you run.

Cake.Frosting is still in alpha, but has been stable enough for us to rely upon it.

P.S. @patriksvensson what's stopping a stable release for Cake.Frosting? If you need help..

[adamhathcock]

That doesn’t seem desirable to me.

I want a cake file that’s an easy script to read for gluing builds together.

The worst part of cake has always been invoking it. Installing a global tool that’s just “cake -t build” or something seems great to me.

[phillipsj]

That is why both options exist. I will pick back up work for the tool
later this month.

On Tue, Feb 6, 2018, 3:41 PM Adam Hathcock [e-mail] wrote:

That doesn’t seem desirable to me.

I want a cake file that’s an easy script to read for gluing builds
together.

The worst part of cake has always been invoking it. Installing a global
tool that’s just “cake -t build” or something seems great to me.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cake-build/cake/issues/1644#issuecomment-363558351,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfthUYb8NmOc7x1i6tsgWj1jLUBOD5fks5tSLkAgaJpZM4N5j50
.

[ErikSchierboom]

This would be great to have.

The worst part of cake has always been invoking it. Installing a global tool that’s just “cake -t build” or something seems great to me.

Completely agree. By the way, Fake now supports this.

[amoerie]

Ah, with the advent of dotnet global tools, I will close this issue in favor of #2067