C# Batch job Issue

Question

Hello,

My current company has 70 batch jobs and each batch job is as separate exe and got scheduled in windows scheduler. The problem with this approach is Maintenance . Even though no dependency b/w exe’s, but maintenance is Costly.

I have another approach which I followed in my previous company like Create one project (one exe) and pass the bath type in command line arguments and based on the argument corresponding business calls to get the logistics executed something like below.

E:\Test\BatchRunner\BatchRunner.exe /Jobs:ProcessEmployee /ProcessMonth 07-01-2014 /CompanyId 1052
E:\Test\BatchRunner\BatchRunner.exe /Jobs:ProcessCompany
E:\Test\BatchRunner\BatchRunner.exe" /Import:ScrapData

So one exe could be used by multiple process. Please let me know which one is best way and drawbacks? If the second approach is good, Is there a best library to parse the command line arguments for .net core? Please suggest me.

Answer 1

I've done it both ways and I would argue that there are plusses and minuses to both approaches. Which one is best for you depends on what your processes are doing. Let's break down the pros/cons of having a single binary.

Pros:

• Updating the code to newer frameworks/libraries is simply a matter of updating a single project (or set therein) and recompiling.
• Any code that is the same across all the processes can be written once and reused.
• Changes to configurations (such as databases, endpoints, etc) can be done in a single (set of) configurations instead of many.

Cons:

• You have to write code to "select" the "process" to run (such as via cmd line).
• Reuseable code has to be more flexible given that it is now being used in "processes" that may behave differently.
• Configurations for all "processes" must be stored together making it harder to know what processes' rely on which dependencies and, in cases where there is overlap, could be conflicting.
• Even if you need to make a minor change to a single piece of code you'll end up needing to retest all the "processes" because they are all impacted even if they don't use the particular area of the code you touched.

Now the pros/cons of separate binaries.

Pros:

• Each process needs to have only the things it requires generally resulting in smaller codebases and dependencies.
• Each process is stand alone so you can, for example, upgrade one process to use a newer library without impacting any of the others allowing for faster testing and minimizing impact.
• Each process is independent so there are no issues with conflicts between processes such as the connection strings to use, the versions of libraries to depend on, etc.

Cons:

• Any shared code either needs to be replicated across codebases or placed into a reusable library.
• More files to deploy since each process would have its own copy of dependencies.

In my experience, if all the "processes" are very similar and only vary by simple things like a report to run or a database to connect to then a single process makes the most sense. However if your "processes" are quite a bit different (e.g. one process to generate reports, another to upload documents, etc) then using a single process provides no real benefit. It just adds complexity with no inherent value add. You're still going to have separate "jobs" to schedule whether they are the same binary or not, you'll be configuring the same sets of stuff and any shared logic can always be put into reusable libraries.

In general I would always use separate processes unless there is an overwhelming positive reason to do otherwise.

.NET Core has a command line parsing library already.

Answer 2

I don't see the maintenance problem. How is having 70 logic paths in the code any better. if you combine them to one exe, you should have a driver program and make a separate project per job,

Maybe you need to work on your Dev Ops pipeline instead.