0

I need to create some functionality in our large C# software package that will use .NET DLLs from a third party software package. Not all of our customers are going to use this package. If I add a reference to those DLLs in Visual Studio I can access the objects I need from them, but I assume that will break the build for other developers in my company who won't have this third party package installed.

What is the correct approach for me to be able to access this third party functionality without breaking things for customers and developers who won't use that package? Do I need to address this by creating my own DLL as a layer of indirection? Do I need to dynamically load the third party DLLs at runtime?

skiphoppy
  • 97,646
  • 72
  • 174
  • 218
  • 1
    What technology do you use? Is the application a .NET application and the DLL in question a .NET DLL or a native Windows DLL? – Codor Mar 24 '16 at 15:32
  • 1
    Ours is .NET, and I believe the DLL in question is .NET as well. I am able to add it as a reference in a trivial application and make calls to it from C#. – skiphoppy Mar 24 '16 at 15:34
  • 1
    You already know the answer, very hard to guess what else you need. Lots and lots of google hits already on a "c# plugin framework" query, you don't need one more. – Hans Passant Mar 24 '16 at 15:39
  • @HansPassant, that is so disrespectful. No, I do not already know the answer, or else I would not be asking it. Nor did I know to Google for "C# plugin framework." – skiphoppy Mar 24 '16 at 16:48

3 Answers3

1

To my understanding, a .NET DLL is not loaded by the application until it is actually needed. This means if the DLL is referenced, but no code branch making use of it is reached, it is not required to be present. Perhaps it is not necessary to implement something in this case.

That being said, it is possible to use a technique termed 'hot loading', which means using reflection to explicitly access types contained in a .NET DLL. The technique is discussed in this question.

Community
  • 1
  • 1
Codor
  • 17,447
  • 9
  • 29
  • 56
1

First, check if it has already been loaded; if not, check if the .DLL exists, and if so, dynamically load it with System.Reflection.Assembly.LoadFile. The reason you want to check if it has already been loaded is because the dynamic loader will often waste memory by loading additional instances.

It will be a bit more work, but by handling this dynamically, you can enable/disable functionality in your application that requires the assembly based on whether it is present, which will minimize unnecessary error reports from people trying to use it when it is not there.

Be careful in referencing the assembly when it is not there; although .NET will usually dynamically load only when an assembly is needed, newer versions are getting more aggressive in how they load, to prevent startup delays, so even if it works now (and that depends on the overall configuration), it may not work in the near future.

Matt Jordan
  • 2,133
  • 9
  • 10
1

It looks like I will be using dynamic loading as described enter link description here. Props to Alberto for showing how to use the dynamic keyword with his answer.

Community
  • 1
  • 1
skiphoppy
  • 97,646
  • 72
  • 174
  • 218