Home/ Questions/Q 6058539
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T08:36:37+00:00

We’re building a .NET software platform for test automation for in house use in

  • 0

We’re building a .NET software platform for test automation for in house use in our company.

The application is composed of a GUI (WinForms) component, and various “Actions” that are dynamically being loaded into it to be executed.

There are approximately ~ 100 Action projects going already, with this number increasing.
Some of these projects are interdependent on other projects and so on.

All actions loaded must reference our “SDK” dll for various activities (results to the main app, logging, etc).

With this relatively simple design, we are facing some management decisions that we’d like to solve in the best way:

  1. Should actions (“plugins”) reference our SDKs project output, or some known stable version of it?
    For example, when developing a large application (MS Office just for the example), not all teams work with source code for all components naturally.

What is the best solution for something like this ? and why?

  1. How to properly verify that all needed dependencies (3rd party libraries for example) are indeed taken from the correct location ?

What are common practices in scenarios where managing multitude of projects that are linked in between? are there any tips for doing so ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is a problem that doesn’t have a clear answer, but…

    There are two paths you can take. A strongly coupled system or a loosely coupled system.

    For a strongly coupled system I can suggest two directories for binaries: a 3rd party directory and a directory that houses DLLs that you company builds that other developers can reference. The 3rd party DLLs (outside your company) should be located in source control so that all developers reference the same versions of the 3rd party DLLs from the same location this avoids developer machine inconsistencies and having the problems of installing 3rd party software on every machine. The in house DLLs should not be referenced in source control and should be built on each developers machine via an automated build batch file or similiar. In a build post step you can copy them all to the same directory and as long as developers get the latest source control and build, everyone has the same DLLs from within your company.

    For example, get latest, build (using a batch file to build all the projects needed), and then as a post build step copy the output to common. Now all of your other projects can reference the common compnay DLLs and the third party DLLs from the same location and everyone is consistent.

    The problem is that the references are strong coupled, so changes can sometimes be problematic if not communicated properly.

    A loosely coupled system uses a framework such as MEF (Managed Extensibility Framework) and your components reference “Contract DLL” which define the interfaces for your components. The project reference the interface or contract DLLs and don’t really care about the implementation and then MEF manages the plugin for you.

    In this case, you reference the interface DLL but not the actual DLL that implements.

    For example, say I have an interface called ILog with a method called LogMessage.

    private ILog _logger;
_logger.LogMessage();

    So, in a strongly coupled case: Action.DLL references Logger.DLL directly.

    In a loosely coupled case Action.DLL references ILog.DLL (just the interface). Logger.DLL implements ILog.DLL. But Action.DLL has no refernce to Logger.DLL directly.

    Now I can have any number of DLLs that implment the ILog interface, but the Action.DLL does not reference them directly. That’s pretty cool and one of the more exciting features of MEF and loose coupling in general, the ability to not to have dependencies.

    How you choose to go, either way is acceptable, I think the loosely coupled idea fits your scenario the best as teams would just have to know the contracts versus the actual implementations.

    I wouldn’t have one massive contract DLL, I would try and break the interfaces into logical groupings. For example, logging seems like a Utility type of interfance, so I would create a Utility contract DLL with a ILog interface. How it is split up depends on what you are trying to do. Or each interface could be a contract DLL, but maybe that is a little extreme.

    • 0