-3

I have a bunch of scripts written in .bat files that I'm trying to implement into one big program using C#. These .bat files mostly do simple operations like copying files into network drives etc. Would it be better to implement the batfile functionality with C# or just call the .bat files using C# and System.Diagnostics.Process?

Pros of using C#:

  1. Better error checking? (i.e copy failed can throw exception etc)
  2. Better performance?

Pros of calling .bat file:

  1. System expert can modify (part of) the program without touching my code (modify .bat files)
  2. The .bat file is confirmed working with the current process less chance of error?
Lightsout
  • 125
  • 3
  • The first pro sounds like a recipe for disaster. Your second pro depends entirely on your C# skills. Also: Companies that rely on .bat files for their daily business worry me. – SKull Dec 28 '21 at 00:04
  • The first pro sounds like a recipe for disaster. What do you mean by this? – Lightsout Dec 28 '21 at 00:14
  • 1
    Because when you let other people willy nilly change your code, you're gonna get a lot of weird support cases all of a sudden. And everybody will deny having changed anything. – SKull Dec 28 '21 at 01:40
  • Your pros on calling .bat file are at odds to me. If #1 is true, _`People can modify ... the program without touching my code'_, then I only see #2, _'The .bat file is confirmed working with the current process'_, would only ever be true at deployment, as someone could change the .bat file and break it. – quaabaam Dec 28 '21 at 01:54
  • I think it really depends on your goals. Both have pros and cons. Long term, C# over .bat files is probably the way to go, but I'm assuming a lot with that statement. More pros with C#, you can implement logging and alerting with less effort. Say you get to a point where you want to log errors for review or send email alerts to users, then C# would make this much easier on you. – quaabaam Dec 28 '21 at 02:00
  • A 3rd option could be hybrid approach, you could store (encapsulate) your .bat code in C# Resource files, this will allow you to control the .bat code along with your C# code. Then you could gradually replace the .bat code files with C# implementations as needed. – quaabaam Dec 28 '21 at 02:01
  • @SKull thats insane imo anyone caught lying at work is gonna get into some big trouble – Lightsout Dec 28 '21 at 02:15
  • 2
    @bakalolo I really admire your optimism. – SKull Dec 28 '21 at 22:54
  • Another possibility: rewrite it in Powershell. – pjc50 Dec 29 '21 at 17:00

3 Answers3

5

I think you got the pros and cons only partially correct. Converting to C# offers you surely the widest range of options for turning a bunch of scripts into a larger program. And though the idea of getting "better performance" is most probably wrong for file copy operations (which are restricted by the performance of the underlying network and file system, not by the language), error handling, logging, and especially debugging will surely be more effective when using C# and an IDE like Visual Studio. (Not to mention all the great things Visual Studio offers only for C#, like Intellisense, refactoring or automatically finding references - I don't think something similar exists for .bat scripts).

On the other hand, there are the two main drawbacks you have to consider:

  1. For maintenance and evolvement, you always need a C# developer, and a C# development environment. You cannot let someone else maintain the program who has only experience with a text editor and scripting, and you cannot easily let someone else make some ad-hoc changes to the (compiled) program in their usage environment, as it would be possible when the program is a script.

  2. You will have to rewrite existing, working functionality in C#. This might be an issue if the existing "bat" files already have a certain complexity.

However, if #1 is really a drawback is debatable. By allowing half-taught "system experts" to fiddle around with some scripts chances are high they unintentionally produce some damage. If the intention of letting "system experts" modifying those scripts is just to let them adapt network adresses or file system paths, then go for C#, but provide a confguration file where the experts can change those parameters.

Another alternative to consider would be to convert your current bat files to Powershell. This has the advantage that it is more suited for the kind of operations you mentioned as requirements of your current scripts, and the disadvantage that for maintaining the code you will need to learn Powershell (or find a Powershell expert). The IDE support for Powershell is somewhere "in the middle" between C# and ".bat" files.

So in the end, this boils down to the effort for rewriting the existing code in another language (with the risk of introducing errors into things which work now), in comparison to the benefits you get from a full-fledged .Net program written in a language like C#. You need to make a cost/benefit analysis for this decision as well as a risk analysus, this is nothing we can do for you.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
3

The key question here is not the technical merits or c# over bat files but your organisations approach to the underlying processes.

If the organisation is trying to formalise the processes, so that they always happen the same way and can be automated as much as possible; then you will want to ensure that the code used is always the correct version, changes are controlled, input is validated, it has a user interface which requires minimal changes, errors are caught, audit trails are kept etc.

These things soon becomes too much for bat files and even powershell will be stretched.

Additionally, professional dev practices like source control, versioning, deployment etc are designed with these non functional requirements in mind and geared towards compiled 'proper' programming languages.

Your choice should be to implement the whole process in a website or other accessible application, in a 'proper' language.

However! Its not always the case that the organisation wants to formalise their processes. If the workforce is technically proficient in the scripting language and the process is required to be flexible and 'human', each engineer will want to have their own customised script library to automate their work which they are able to update and change as they require. A UI will not be desired as cli commands will be preferred because they can be called from other scripts. Logging and audit trails will be seen as unnecessary 'red tape' that gets in the way of productivity.

If you try to formalise the processes in such an environment your application will quickly become out of date and unused. Key assumption about the process that it will rely on to successfully work will not be followed and the app will cease to function correctly.

In such a case moving away from the scripts is a mistake. You have to recognise the human factor, in formalising the application you are changing peoples work day, you are changing their job. This can only be done if it is enforced by the organisation, or supported by the workers involved.

Ewan
  • 70,664
  • 5
  • 76
  • 161
0

If these scripts already works and are battle-tested, it sounds like a sensible approach to keep them. Rewriting in C# would cost time and effort and introduce risk, so it should provide a clear benefit.

You mention performance and error-checking as possible benefits, but does the existing solution have known problems with performance or errors?

JacquesB
  • 57,310
  • 21
  • 127
  • 176