Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

You don’t need Cake anymore; the way to build .NET projects going forward. #10

Open
pauldotknopf opened this issue Mar 10, 2019 · 14 comments

Comments

@pauldotknopf
Copy link
Owner

@pauldotknopf pauldotknopf commented Mar 10, 2019

https://pknopf.com/post/2019-03-10-you-dont-need-cake-anymore-the-way-to-build-dotnet-projects-going-forward/

@VictorioBerra
Copy link

@VictorioBerra VictorioBerra commented Jul 26, 2019

Are Bullseye and NUKE mutually exclusive? Would I use one or the other? Would I use both together? The article makes it sound like you would use all three (NUKE, Bulls, SimpleExec)

@pauldotknopf
Copy link
Owner Author

@pauldotknopf pauldotknopf commented Jul 26, 2019

They are mutually exclusive. I'm sorry I wasn't more clear. I was trying to list multiple alternatives to Cake.


Option 1

NUKE:

  • Targets
  • Process running
  • ...and a lot more (than you'd probably need).

Option 2

Bullseye

  • Targets

SimpleExec

  • Process running

Bullseye and SimpleExec are a perfect fit to be used together.

@VictorioBerra
Copy link

@VictorioBerra VictorioBerra commented Jul 26, 2019

Awesome, thanks for clarifying and replying so quickly.

@VictorioBerra
Copy link

@VictorioBerra VictorioBerra commented Jul 26, 2019

I also want to plug this here https://github.com/cake-build/frosting by the cake-build team.

It works similar to NUKE but it's more coreesq in the way that it's an actual host.

@VictorioBerra
Copy link

@VictorioBerra VictorioBerra commented Jul 26, 2019

Its V0.x.* so id regard it as experimental. Even though its been around for a good while now.

@pauldotknopf
Copy link
Owner Author

@pauldotknopf pauldotknopf commented Jul 26, 2019

I've asked the devs of Cake what it's status of Frosting is. No word. It seems inactive to me.

Also, I mentioned this in my post.

I believe the maintainers of Cake recognized this disadvantage when .NET Core initially came on the scene, and started the Frosting project. My memory says that this project had been de facto abandoned, however, it has had some recent commits. Either way, they aren't promoting it. Maybe someone can enlighten me here? Regardless, I wish it had picked up more stream than it did.

@VictorioBerra
Copy link

@VictorioBerra VictorioBerra commented Jul 26, 2019

I wish that too :( it was before its time.

@changhuixu
Copy link

@changhuixu changhuixu commented Jul 31, 2019

Thanks for the great article. Totally agree.

@smaudet
Copy link

@smaudet smaudet commented Sep 10, 2019

Seems like there are still commits as of last month...on that frosting project...

Cake's runtime is heavy and I don't like the fact that it's pseudo C#, no... but then again I really don't like to script in C#. Such a heavy language to script in at all.

I'd offer a hypothesis why they're not promoting Frosting - they are probably too busy supporting their mainline and don't have a clear migration strategy (yet) (it also looks like its a one man-op so that's why they're not busy figuring our their marketing and product strategies - nobody to market or product plan).

"You'd be just as comfortable writing a regular C# project. Even more so, considering you'd have complete IDE and debugger support!"

Ugh, no? I don't like re-implementing everything from scratch? Better msbuild support is always welcome, but if its too opaque (which it will probably become over time as the msbuild devs "abstract" functionality away in a misguided effort to make things "simpler") then its no good and something like Cake will be needed/reborn anyways.

Syntax completion and IDE support can be provided by proper language support for a language. Maybe Cake's DSL isn't necessary, I'd prefer to see e.g. a Python or JS based DSL for invoking C# targets. I don't really care what it is, I just don't care to re-implement the world every time.

@pauldotknopf
Copy link
Owner Author

@pauldotknopf pauldotknopf commented Sep 13, 2019

Cake's runtime is heavy and I don't like the fact that it's pseudo C#, no... but then again I really don't like to script in C#. Such a heavy language to script in at all.

What other language would you like to use? Standard Makefile? bash?

I don't like re-implementing everything from scratch? Better msbuild support is always welcome, but if its too opaque (which it will probably become over time as the msbuild devs "abstract" functionality away in a misguided effort to make things "simpler") then its no good and something like Cake will be needed/reborn anyways.

The future is the dotnet cli. MSBuild will always be a pain. And if you need to use it, you still don't need Cake. That's like saying "I need to hang this picture frame, so I need a sledge hammer". NUKE has a good abstraction around MSBuild, and it doesn't require you to buy-in to the pseudo C# to use it.

I sense a recurring theme:

I just don't care to re-implement the world every time.

What exactly do you mean by this? What exactly would you need to re-implement that the .NET framework doesn't provide for you? You have System.Diagnostics.Process for shelling out CLI stuff, System.IO for directory cleaning and file modifications, etc.

@unikzforce
Copy link

@unikzforce unikzforce commented Oct 9, 2019

Cake's runtime is heavy and I don't like the fact that it's pseudo C#, no... but then again I really don't like to script in C#. Such a heavy language to script in at all.

What is the meaning of a light language?

@nick5454
Copy link

@nick5454 nick5454 commented Jun 3, 2020

The real question is, do you support building iOS and Android? The scripting looks too heavy to me and I would much rather use a wrapper as opposed to a command line for obvious reasons. ( based on your comment in the article )

But, as stated can we use Nuke to deploy to iOS? I just don't want to be switching. I use Nuke for this, but for these 2 projects I have to use Cake...

I see nothing about iOS on the website

@pomma89
Copy link

@pomma89 pomma89 commented Jul 16, 2020

@pauldotknopf I would like to thank you for you post. I added dotnet-script to the mix, in order to obtain a single file build script: the result is very clean and flexible.

For example, following build.csx is a good example of the final result:

#r "nuget: Bullseye, 3.3.0"
#r "nuget: CommandLineParser, 2.8.0"
#r "nuget: SimpleExec, 6.2.0"

using System.IO;
using CommandLine;
using static Bullseye.Targets;
using static SimpleExec.Command;

////////////////////////////////////////////////////////////////////////////////
// PREPARATION
////////////////////////////////////////////////////////////////////////////////

var artifactsDir = "./artifacts";
var nugetPackagesDir = $"./{artifactsDir}/nuget-packages";
var testResultsDir = $"../../{artifactsDir}/test-results";

////////////////////////////////////////////////////////////////////////////////
// OPTIONS
////////////////////////////////////////////////////////////////////////////////

public sealed class Options
{
    [Option('c', "configuration", Required = false, Default = "release")]
    public string Configuration { get; set; }

    public string ConfigurationFlag => !string.IsNullOrWhiteSpace(Configuration) ? $"-c {Configuration}" : string.Empty;

    [Option('t', "target", Required = false, Default = "run-unit-tests")]
    public string Target { get; set; }
}

Options opts;

////////////////////////////////////////////////////////////////////////////////
// TARGETS
////////////////////////////////////////////////////////////////////////////////

Target("clean-solution", () =>
{
    Run("dotnet", $"clean {opts.ConfigurationFlag}");

    if (Directory.Exists(artifactsDir))
    {
        Directory.Delete(artifactsDir, recursive: true);
    }
});

Target("check-source-code-format", DependsOn("clean-solution"), () =>
{
    Run("dotnet", "format --check --verbosity detailed");
});

Target("restore-nuget-packages", DependsOn("check-source-code-format"), () =>
{
    Run("dotnet", $"restore");
});

Target("build-solution", DependsOn("restore-nuget-packages"), () =>
{
    Run("dotnet", $"build {opts.ConfigurationFlag} --no-restore");
});

Target("run-unit-tests", DependsOn("build-solution"), () =>
{
    var logger = $"junit;LogFilePath={testResultsDir}/{{assembly}}-{{framework}}.xml";
    Run("dotnet", $"test {opts.ConfigurationFlag} -a . -l {logger} --no-build");
});

Target("pack-sources", DependsOn("build-solution"), () =>
{
    Run("dotnet", $"pack {opts.ConfigurationFlag} -o {nugetPackagesDir} --no-build");
});

Target("publish-on-myget", DependsOn("pack-sources"), () =>
{
    var mygetApiKey = Environment.GetEnvironmentVariable("MYGET_API_KEY");
    Run("dotnet", $"nuget push {nugetPackagesDir}/*.nupkg -k {mygetApiKey}");
});

////////////////////////////////////////////////////////////////////////////////
// EXECUTION
////////////////////////////////////////////////////////////////////////////////

Parser.Default.ParseArguments<Options>(Args).WithParsed<Options>(o =>
{
    opts = o;
    RunTargetsAndExit(new[] { opts.Target });
});

Bye, Alessio

@smaudet
Copy link

@smaudet smaudet commented Mar 16, 2021

@pauldotknopf

What exactly would you need to re-implement that the .NET framework doesn't provide for you?

Its a late reply, but this smacks of some learned helplessness or something...

Yes, if the .NET framework is so great, maybe you don't even need to program at all? :P I mean it does everything already for you sarcasm.

The .net framework has actually a really horribly bad philosophy, from what I can tell, it very much generally promotes programming "within the rails", especially the new build formats etc are more prone to assuming you wanted to do one thing that was already done by somebody somewhere else... and then its impossible to actually do what you want to do or simple things are made arbitrarily complex for no good reason...

The job of a framework is not to presume you know what people want to do, but to presume you do not know what people want to do, just to provide some nice tools for some features that seem to be generally helpful.

I'm not saying a framework can't have nice libraries for builds or whatever, that doesn't eliminate the need for other libraries, either as replacements, shims, additions, stability abstractions, or whatnot. That's where your post is wrong on a very fundamental level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants