Consuming a DLL in EXE

Question

I had a discussion with friends last week about consuming the classes which are in DLL(.net DLL). I have a .net DLL which I need consume it in my Exe.

Normally,

I add the DLL in my solution and reference the DLL in my Exe
Create the object of the Class(which is in my DLL)
Start calling methods /function in the class from the object just created.

But finally decided that, We should use Reflection not the way we are doing. Reason is Loose coupling. One can change the functionality in the DLL and compile it. In such situations, You don't need to compile client code.

I have a question with this background.

Suppose, I have an a very simple application(Say console application) and I have two classes both are writtern to do different work.

class Program
{
    static void Main()
    {

        //How do you create a object of the class A. 

    }
}


class A
{

    string A = "I am from A";
    public B b; 
    public A
    {
        b = new B();

    }
}

class B
{

    string B = "I am from B";
    public B
    {

    }
    public void Print()
    {
        Console.WriteLine(B);
    }
}

How do you create the object of Class A when all the three classes the same exe and how you create the same object when Class A and class B in different DLL.

one answer for the sencond part of the question is use interface and use reflection.

Is reflection is it really required, or it is kind of programming standard.

What is the best practice to create an object of the class.

Interfaces is the right way of achieving loose-coupling. I'm not sure about using reflection to achieve loose-coupling but any good pattern/methodology will not involve using reflection. — Bala R, Sep 20 '11 at 02:07
Generally speaking, you don't need to recompile/deploy the .exe in C# *not* using reflection unless you change method names/signatures/etc actually being used in the .exe, in which case you would have to recompile in any case. Use interfaces without reflection and you should be fine. — Kevin Stricker, Sep 20 '11 at 02:13
Yes, please don't attempt to use reflection to replicate the functionality of a class library... — Ed S., Sep 20 '11 at 02:14

bryanmac · Accepted Answer · 2011-09-20T02:36:06.490

Interfaces provide a way to have loose coupling.

If you want to provide the ability to extend or replace the functionality after the fact without recompiling or even redeploying, then you're basically looking at a plug-in type architecture on top of the interface based loose coupling.

You could either use reflection to iterate and create an instance of the object but the other option is configuration/registration. For example, in your config file (or registry etc...) you could point to the file and class that implements that interface and use System.Activator to create it at runtime.

Example:

http://msdn.microsoft.com/en-us/library/ms972962.aspx

Another more robust option is MEF. It's a plug-in framework developed b the .net framework team.

Check out this link:

http://mef.codeplex.com/

From that link (reenforcing your question):

"Application requirements change frequently and software is constantly evolving. As a result, such applications often become monolithic making it difficult to add new functionality. The Managed Extensibility Framework (MEF) is a new library in .NET Framework 4 and Silverlight 4 that addresses this problem by simplifying the design of extensible applications and components. "

Hope that helps.

Consuming a DLL in EXE

1 Answers1