Referencing methods in separate class library that may not be loaded

systemlordanubis

New member
Joined
Aug 6, 2018
Messages
2
Programming Experience
10+
Hi,

I would like to understand what methods might be possible to solve this scenario...

Let's say, I have a primary class library "classmain.dll" and a secondary library "classsec.dll".

Within "classsec.dll", I have a public method "checkstatus()" which performs some work. In the "classmain.dll", I have another method(s) which reference or call "checkstatus()".

However, what I would like to do, in some instances, is not include "classsec.dll" with the application (as perhaps its an additional module the client optionally needs to pay for); yet, unless I explicitly reference "classsec.dll" in the project, I can't compile "classmain.dll".

What I would like to achieve is to be able to alias (or similar) the "checkstatus()" method within "classmain.dll" such that I can handle an appropriate error response if "classsec.dll" is missing; but, if "classsec.dll" is present when the application is run, then it would utilize that method in place of the aliased version in "classmain.dll".

Hopefully, that explains the situation clear enough.

Thanks
Anubis
 

jmcilhinney

C# Forum Moderator
Staff member
Joined
Apr 23, 2011
Messages
2,860
Location
Sydney, Australia
Programming Experience
10+
If you don't want your main assembly to be dependent on the library then don't make it dependent. That means not writing any code that explicitly refers to it. You would need to load the assembly dynamically and invoke the functionality it contains using Reflection. You might look for information on implementing a plugin system, as that's the sort of thing you will need to do. It may not need to be quite so general as that but many of the same principles apply.
 

Skydiver

Staff member
Joined
Apr 6, 2019
Messages
1,227
Location
Virginia Beach, VA
Programming Experience
10+
Look at using MEF (Managed Extensibility Framework) if you don't want to roll your own plugin system.

But even if you roll your own plugin system, you should really follow the 'L', 'I', and 'D' of the SOLID object oriented programming principles. This means programming against interfaces instead of concrete objects so that you can use either a do-nothing plugin with a real plugin. (See also Null object pattern.)
 
Top Bottom