A long time ago I used Ant to build a C# project (a Unity3D project, to be precise), but I slowly switched to doing most of the logic in C# itself. Now it's entirely in C#.
I found a lot of benefits by doing this. Off the top of my head:
I don't have much experience with Gradle, but I know that it also handles dependencies. But surely you can create a library in C# that does pretty much what Gradle does.
So why choose yet another tool for something that your language can already do easier (IMO)?
Lets forget about Ant here. There are tons of better tools out there. Lets assume you are talking about maven. Build tools are not tooling libraries. They have one and only one job, to generate a final deployable "unit" (war/jar in case of Java, binaries in case of C++/Go etc.). They don't decide how you create your tooling libraries, hell they use the same libraries that probably you will use to create these "units". So what is the advantage then?
Separation of concern: The idea here is, the development aspect should not be part of your build system. eg. Maven lets you create artefacts without worrying about how it is going to be. It is maven's responsibility, not yours.
Dependency Management: Possibly the most important feature here is this one. There are situations that you will face when you have 2 different incompatible versions of library, how would you manage it. One simple solution is to keep the libraries with you, but then what if you changed your machine or someone else has to use it, will you ask them to download the libraries again
Shipping: This stems out of the previous point. To avoid keeping libraries with you and shipping them as part of source code, there are repositories which contain the versions of these libraries and these build systems are responsible for pulling the correct version of library based on a config. Now all you need to do is ship your code with a config and it is ready to build.
Now, tell me, do you really think for a project with huge number of files and loads of dependencies, is it really easier to add yet another aspect of development, when you have so many other things to worry about?
But surely you can create a library in C# that does pretty much what Gradle does.
But why would you want to re-invent the wheel?
Ant is history, period. Build tools has matured a lot compared to how it was! And I don't know about C#, but in Java, it is not easy to do what Maven does. And it is not worth doing, when we already have a tool for this very purpose. We have a work on our plate, so it is wise to use existing tools to finish up things on time, rather than write those stuffs yourself and complicate it further.
Automate work that is highly repeatable, to reduce mistakes and improve consistency
It's about standards, if you have 50 different projects each with their own different way of doing things, it becomes a nightmare to maintain the build system. Ant itself had this problem since it didn't dictate a single way of building / compiling code and eventually gave rise to Maven which forces you into a very strict process.
If I want to compile any project in my 200+ project directory, I run mvn clean package and I get a standard war file or jar file. Want to run it, I can either run mvn jetty:run or mvn tomcat:run, need to import the project into eclipse, run mvn eclipse:eclipse, want to run unit tests, mvn test, etc etc etc. This applies to my Java and Kotlin projects, old and new.
Although maven is very focussed on JVM languages, I have retrofitted a PHP project to make use of Maven, although I would rather recommend to sticking to the right build system for the job, Maven is heavy JVM focussed so not a good fit for PHP, Composer is a much better fit for PHP.
If there's a specific package management system for C#, I'd rather use that over Gradle or Maven (not a C# developer, so can not recommend anything). I personally find Ant too loosely defined - if I want to run your ant script, I need to read through the script before I understand what you're trying to do and what commands I'm supposed to run, maven I don't even have to look at the pom.xml, chances are mvn clean install will work out of the box.
By the way, I see there's a C# plugin for maven: https://incubator.apache.org/npanday/ If you have to deal with multiple programming languages, pick one build system that will work for all, otherwise pick the one that's best for your single programming language.
I`m with Cliff on this one. Usually I tend to use the ecosystem of as much as possible.
For the C# part I do not always find the libraries that I need but again since I'm writing in with the language it's easier for me to code something that I need instead of adding something else in the mix.
Typically I go for the programmatic tools wherever possible and avoid things like Ant, and usually I use whatever is most appropriate for the ecosystem I'm developing in - so for Ruby that's Rake, Python I usually use Fabric, or Make - sometimes just Bash. Not sure why anyone would use anything else, but I've never been that deep in the Java world to appreciate the rationale behind tools like Ant.
Jan-Stefan Janetzky (GottZ)
Specialist for Computer Science in Software Engineering
if you provide unit tests etc. you could (as example) test your code serversided each time you or one of your collegues pushes a commit into your repository.
this is especially usefull if you want to avoid / pin point breaking changes / bugs.
oh and yep.. ant.. maven.. i dont like any of them. you should just choose the one you have the least problems with aswell as choose an apropriate one suited for your language choice.