none
C# - binding to DLL/assembly at run time RRS feed

  • Question

  • I have written software that controls a piece of equipment to perform a set up tasks. There are several models of this equipment used in industry.   Each of these equipment models have different communication protocols.   I would like to have the same program be used with any of the equipment models/types depending on the equipment type that the user has.   In C++ I used late binding to bind to different DLLs which had the same name and same functions but was different for the different equipment used at this location.   I have the location installed the proper DLL on their system based on the equipment model used at their location.   I wanted to separate the main program form the type of equipment in use; the program would run the same wafer have the same source code but control different equipment.

    My question is how would I do this using best practices in C#.    Is there a more generic way I could do this.

    mainprogram1

        Function1

    ...

        Function2 

    Saturday, March 24, 2018 12:26 AM

All replies

  • Sorry to quick to submit:

    mainprogram1

        Function1   ---> (DLLA) --> EqpType1

    ...

        FunctionN   ---> (DLLA)--> EqpType1

    - or -

    mainprogram1

        Function1   ---> (DLLB) --> EqpType2

    ...

        FunctionN   ---> (DLLB) --> EqpType2

    Where mainprogram1 is the same program  Function1..FunctionN are same Methods calls,  Eqptype1 and 2 do the same actions but are build by different vendors with different communication protocols.

    Saturday, March 24, 2018 12:32 AM
  • My question is how would I do this using best practices in C#.    Is there a more generic way I could do this.

    Maybe you should understand IoC and maybe DI.

    https://www.c-sharpcorner.com/UploadFile/cda5ba/dependency-injection-di-and-inversion-of-control-ioc/

    Saturday, March 24, 2018 1:13 AM
  • For what it is worth, I probably edited the article in C# Corner that DA924x refers to. I did not write it but I probably edited it. I sure don't understand it; I get the impression it is using fancy terms to refer to relatively simple concepts. As best as I understand, Dependency Injection is for making classes dependent on other classes and that is not relevant to you, correct? And injection is for putting more stuff into a class and you probably don't need to do that either.

    Interfaces however can help. They might be perfect for this. Do you understand interfaces? You can create an interface with the methods common to all protocols (such as Function1 through FunctionN). Then each protocol can be in separate Class Libraries, each with a class derived from the interface. And then your main code can create an instance of whichever protocol you need and use the same code thereafter independent of the protocol. That would be object-oriented and as best as I understand what you are saying it is consistent with your original design. Your original design seems to have object-oriented features. Perhaps it will help you to learn more about object-oriented programming.

    There is one thing I am not sure of. I am not sure whether all the Class Libraries would be loaded even if not used (the corresponding class allocated). We could investigate that if it is important.



    Sam Hobbs
    SimpleSamples.Info

    Saturday, March 24, 2018 3:23 AM
  • I expect these equipment are used for same thing (i.e. measurement of something). I would attempt to create communication layer by strategy pattern. Common method/properties are in base (can be abstract) class and concrete thinks for concrete communication protocol are in concreate class inherited from base.
    I assume there would be common method GetValue (or something as entry point) which could be declared in interface which will be implemented by base class. Instance will be as interface type and will be instantiate by concrete class constructor based on type of device.
    Saturday, March 24, 2018 6:00 AM
  • Interfaces and abstract classes are much alike and each has advantages and disadvantages.


    Sam Hobbs
    SimpleSamples.Info

    Saturday, March 24, 2018 7:28 AM
  • I expect these equipment are used for same thing (i.e. measurement of something). I would attempt to create communication layer by strategy pattern. Common method/properties are in base (can be abstract) class and concrete thinks for concrete communication protocol are in concreate class inherited from base.
    I assume there would be common method GetValue (or something as entry point) which could be declared in interface which will be implemented by base class. Instance will be as interface type and will be instantiate by concrete class constructor based on type of device.

    The point is to learn IoC. The DI may not be useful for you at this time, but you  never know when it will come in handy for you.

    Both patterns come into play if you ever get into TDD and unit testing, which a lot of time has to be given to it to learn it.

    As a matter of fact, you should learn how to do TDD and unit testing for the various devices you are talking about,  come to think about it. :)

    Saturday, March 24, 2018 8:13 AM
  • We don't know how complex this task is. If it is about two layer - communication and present, and there are no more than five protocols. I think there will be better factory pattern than IoC. I assume I need more than one concrete protocol at time - application could work with many equipments on different protocols at time. 

    I would create IProtocol interface which will have methods for communication with equipment. Then base abstract class Protocol which will implement interface IProtocol and concrete class inherited from Protocol which will implement concrete protocol details. 

    I would create ProtocolFactory which give me instance IProtocol based on which protocol I want. Then I would created abstract class Equipment which will depend on ProtocolFactory. Concrete equipment class would be know which protocol would be used and can require ProtocolFactory to get. 

    It is testable because you can add ProtocolFactory instance through Equipment constructor so you can change implementation ProtocolFactory as you want because Create method will return IProtocol instance. 

    But it is depend on many information which we do not have. If there will be information to use two protocols only it could be implemented as service locator pattern ... It does matter ... There can be abstract class Protocol but might not ... 

    Saturday, March 24, 2018 9:05 AM
  • But it is depend on many information which we do not have. If there will be information to use two protocols only it could be implemented as service locator pattern ... It does matter ... There can be abstract class Protocol but might not ... 

    Well, that's why one uses TDD and unit testing, because you can unit test an abstract class or a class implementing an Interface, which you can unit test to ensure that various implementations are covered by using  unit tests. And of course,  DI will come into play to mock out functionality.  

    Saturday, March 24, 2018 9:24 AM
  • Some time ago I solved similar problem.
    I prepared "template" project for dll and put all files of this project into the program as resource.

    After my program get all necessary information it writes C# code file into temporary directory with other files of project from resources. After that my program executes MSBuild and target it to the prepared project. After that my program copy just built dll to the target location.

    I use class CSharpCodeProvider to apply MSBuild to code generated by my program.
    Here you can see usable example to use it:
    https://msdn.microsoft.com/en-us/library/microsoft.csharp.csharpcodeprovider(v=vs.110).aspx

    Saturday, March 24, 2018 12:27 PM