CODEWITHSUNDEEP
c#dllreferencelayer
Andreas Reiff
Andreas Reiff

Reputation: 8404

expose a referenced type (class) without need for additional reference

I have a layered system of .dlls between my application, where the lowest level has a class that provides certain functionality - an instance of this class can be received through a GetClass() function and then I can access its properties (basically, a collection of information of changing objects).

Now I noticed that when I want to access that information from the next higher level .dll, the compiler complains that I do not have the lower level .dll referenced (the one defining the class) - which actually I would want to avoid, to have a nice layered structure in my architecture.

How to get around this? Can I re-expose the referenced type? Do I really have to write a wrapper of my own, if I want exactly the same functionality? Or do I even need to reference the low level .dll again?

DLL 1:

class myClass;
myClass GetMyClass();

DLL 2:

myClass GetMyClass();

EXE:

How to access result from calling GetMyClass (DLL 2) without referencing DLL 1?

Upvotes: 6

Views: 5420

Answers (6)

Nevyn
Nevyn

Reputation: 2683

We do something similar to this in our local code. You can load the assembly at runtime, scan the types it contains using reflection, and again using reflection call functions and instantiate types from that dll, without ever referencing it directly in the project.

some of the key functions you will need are:

Assembly.LoadFrom(path); //get the assembly as a local object
Activator.CreateInstance(type); //create an instance of a type
Assembly.GetType(string);//fetch a type by name from the assembly

Once you have the type, basic reflection will give you pretty much every other piece you need.

Here is the snippet from my local code:

asm = Assembly.LoadFrom(Path.Combine(Environment.CurrentDirectory, filePath));

Type[] types = asm.GetTypes();
for (var x = 0; x < types.Length; x++)
{
    var interfaces = types[x].GetInterfaces();
    for (var y = 0; y < interfaces.Length; y++)
    {
        if (interfaces[y].Name.Equals("MyTypeName"))
        {
            isValidmod = true;
            var p = (IMyType)Activator.CreateInstance(types[x]);
                            //Other stuff
            }
    }

Also note: this is pretty old code now. It has been neither reviewed nor refactored in years, so its essentially modern as of .NET 1.1, BUT: It illustrates the point. How to load a type from a remote assembly that is NOT locally referenced.

Additionally, this is part of an engine that loads some 50 of these, given a rigid folder structure, which is why its so generic looking. Take what you need from it.

Upvotes: 2

user22467
user22467

Reputation:

One solution here is to provide a 4th DLL that contains interfaces for your classes. You would reference this in all 3 of your layers, and return these interfaces instead of your classes.

This should give you a good idea of what I mean:

// DLL1
class ClassInDLL1 : IClassInDLL1
{
}

// DLL2
class ClassInDLL2
{
    public IClassInDLL1 GetClassInDLL1()
    {
        return new ClassInDLL1();
    }
}

// DLL3
class ClassInDLL3
{
    public void DoSomething()
    {
        var dll2 = new ClassInDLL2();
        var dll1 = dll2.GetClassInDLL1(); // dll1 variable is of type IClassInDLL1

        // do stuff with dll1
    }
}

// interface DLL
interface IClassInDLL1
{
}

I'll be honest though, layering your architecture like this is usually not an awesome idea unless your project is really large. I find that artificially making assembly splits like this ahead of time can cause you unnecessary pain, not to mention the fact that you end up with 3-4 assemblies for a medium or small project that might only need 1.

Upvotes: 1

Fabio
Fabio

Reputation: 3120

You need to separate all the common classes you use across all your layers into a new dll, then reference this dll on every project.

Try to use interfaces so you can work over the contract (the functionality) instead of the concrete implementation. It will help you to avoid unnecessary references.

// common dll
public interface IMyClass
{
    string MyData { get; set; }
    IMyClass GetMyClass();
}

// dll1
public class myClass : IMyClass
{
    public string MyData { get; set; }
    public IMyClass GetMyClass() { return new myClass() { MyData = "abc" }; }
}

// dll2
public class myClass2
{
    public IMyClass GetMyClass()
    {
         var c1 = new myClass();
         var c2 = c1.GetMyClass();
         return c2;
    }
}

// exe (references common and dll2)
public class Program
{
    public static void Main(string[] args)
    {
        var c1 = new myClass2();
        IMyClass c2 = c1.GetMyClass();
        Console.Writeline(c2.MyData);
    }
}

Upvotes: 4

Joe Pattom
Joe Pattom

Reputation: 21

I go with Nick using any Ioc framework like spring.net or microsoft unity. to get the idea properly go through http://martinfowler.com/articles/injection.html

Upvotes: 1

Alex Tsvetkov
Alex Tsvetkov

Reputation: 1659

Seems no way to achieve this, if myClass is defined in dll1, since objects of type myClass may be instantiated at runtime. To avoid this, you need to change the return type of GetMyClass() in dll2 to return something defined in dll2. It can be a class quite similar to myClass and having the same properties (you can even use tools like AutoMapper to easily convert between objects), but it definitely should be in dll2. Something like:

// dll1
class myClass
{
    ...
}

myClass GetMyClass()
{
    ...
}

// dll2
class myClass2
{
    public myClass2(myClass c)
    {
        // instantiate myClass2 with values from myClass
    }
}

myClass2 GetMyClass()
{
    // somehow get myClass and convert it to myClass2 here
}

Upvotes: 2

awright18
awright18

Reputation: 2333

The caller must have a reference to the class in DLL1 to know what type it is accessing. So yes you need to reference the first dll in the exe. Since GetMyClass() returns a type in DLL1 the type needs to be exposed in the exe, therefore dll1 must be referenced.

Upvotes: 1

Related Questions