Multiple DLLs vs Multiple EXE's in a project that needs to be modular (web browsing automation)

Question

First of all, C# solutions are needed.

So in my team I am responsible for creating a program that will receive a "task" in json format from an API, from this json it needs to figure out what website to create an account for, for example:

• wordpress.com
• weebly.com
• whatever.com

Now, each of these sites will have separate logic for using a browser to navigate, click and type text, to finally create an account and report back to the API.

My problem is: Which option is gonna be easier to mantain in the future since we are gonna be automating probably 25+ websites with account creation.

• One DLL for each website logic
• One separate program (.exe) for each website logic
• I am also open to any options you have to offer.

What needs to be kept in mind is that when a logic breaks, we need to update that logic, and everything needs to be updated automatically, so im not sure if DLLs can be replaced while an APP is running.

Thoughts?

EDIT:

Thanks, by the way, what do you think about code repetition? For example:

Wordpress bot needs to

• Parse JSON data from command line
• Launch Browser
• Create account on wordpress(lots of different instructions)
• Report task status to server.

Weebly bot needs to

• Parse JSON data from command line
• Launch Browser
• Create account on weebly(lots of different instructions)
• Report task status to server

See the repetition?

Now I guess it could be simplified to: - JsonParser.dll - Browser.dll - TaskReporting.dll

Or is there a better way to make stuff less repeated?

Beacause if lets say i need to add another BOT to the arsenal for any other website it would still have to:

• Parse JSON
• Work with the browser
• Report to server about task status

Answer 1

As you are mentioning .exe as the executable suffix, I assume you are working on Windows. Here, it is (at least in principle) possible to dynamically load and unload dynamic libraries, either via

• delay loading (via the linker flag /DELAYLOAD)
• run-time dynamic linking (via Windows API functions LoadLibrary(), GetProcAddress(), FreeLibrary())

Both approaches support unloading the dynamic libraries, but I have never seen delay loading in the wild, while run-time dynamic linking is quite common to create plugin systems.

This can e.g. be done by giving all plugin libraries a somewhat generic interface and putting then into a common directory. Then, the host application can load all dynamic libraries from the directory and use the generic interface to query their capabilities and unload them again. If some functionality is needed, the respective plugin can be loaded, used and unloaded again. Thus, exchanging one of the plugins should be easy without having to stop/restart the host.

Clearly, the same will be possible if you just place a bunch of executables with a generic command line interface and some meta-information with their capabilities in the plugin directory.

Ad-hoc I am seeing the following properties of the different approaches (maybe others will find more):

using executables:

• Perfect address space and execution separation: If such an executable crashes, the host application will not be influenced.
• Difficulties when exchanging large data sets between host and plugin: All data will have to be passed vial command line or via disk (or memory mapped files for performance).
• For getting information back from the plugin, you will have to parse command line output or detour via the disk as well.
• Program invocation requires operating system overhead, which might only be relevant in performance-critical scenarios.
• Stand-alone tests of the plugins do not need a host application.

using dynamic libraries

• Shared address space: Exchanging data between host and plugin can be done trivially in memory. This is also true for returning data from the plugin.
• Loading and unloading the dynamic libraries should in general be cheaper than running a separate program (no proof here).
• Stand-alone tests of the plugins will need a host application.