0

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
Improve this question
2
  • Why isn't the website server-side logic itself not handling account creation?
    – user232573
    Mar 5, 2019 at 20:10
  • @Orangesandlemons Because for that is needed a real browser to automate, we use a library called Selenium for C# to automate Chrome. The API is web based, the "Bots" that will create the accounts are gonna be ran on windows servers
    – Joao Vitor
    Mar 5, 2019 at 20:43

1 Answer 1

Reset to default
3

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

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.
Improve this answer
14
  • Thanks for your answer, using executables seem to have a slight advantage? What would you choose? Opinion based i know but you have facts to back it up.
    – Joao Vitor
    Mar 5, 2019 at 23:33
  • Also forgot to add that this should be exclusively C#. I tried that with reflection but I can't seem to unload the libraries after use.
    – Joao Vitor
    Mar 5, 2019 at 23:36
  • I am not too much into C#, but looking at stackoverflow.com/a/23623244/10984529, I suspect that the run-time dynamic linking should also be possible there.
    – dasmy
    Mar 6, 2019 at 8:22
  • The actual choice is maybe not too much about opinion but your use case: I assume your application is neither performance-critical nor exchanging large data sets. Thus, the approach using individual executables seems favorable. In particular this also avoids having to deal with calling LoadLibrary et al. from C#. Still you should ensure that the individual plugin executables do have a well-defined interface and are accompanied by appropriate meta-data (e.g. in an additional file) to avoid having to change the host application whenever a new plugin is created.
    – dasmy
    Mar 6, 2019 at 8:24
  • By interface do you mean what? That each individual plugin executable would react to the command line input the same? And im not sure about the meta-data part you mentioned, can you clarify?
    – Joao Vitor
    Mar 6, 2019 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.