Question

I am utilising a 3rd party .net dll, which I am making calls to. I am simplifying my code, but it’s something like this.

// The assembly has already been loaded into 'ass'

Type params = ass.GetType("RemoteCalls.ParametersDelegate");
Delegate UseDel = Delegate.CreateDelegate(params, this, "MyGetParams");

I can then pass this delegate (UseDel) into the reflected object, and it will call MyGetParams when it needs to.

The problem I’m having is that the method signature is made up of a type within the 3rd party dll.

The signature of the ParametersDelegate is…

Parameters GetPars();

So, my method can’t return the correct type (Parameters). I have tried the following..

private static class OtherDelegates<T>
{
    public static T MyGetParams()
    {
        //... code to build up the 'Parameters' class, and return it.
    }
}

Then calling..

Delegate UseDel = Delegate.CreateDelegate(params, this, "OtherDelegates<xxx>.MyGetParams");

But I can’t work out what to put in ‘xxx’.

I think that I might be able to do this by using CodeDomProvider , but wondered if there is a simpler way ?

Also, it’s not an option to add the DLL as a reference due to licensing issues.

Thanks
Rich.

Answer 1

I would completely encapsulate the third party dll behind a library dll that you control, using none of the 3rd-party types on the interface. This means you can reference your (already built) library dll in isolation. Obviously you still need to code in sch a way that it fails gracefully when the 3rd party dll is not available.

This also has side benefits:

• you can mock the implemetation for testing
• you can provide a fallback strategy the 3rd party dll isn’t there
• you can potentially support multiple providers

I’ve used the above very successfully, for example wrapping MapPoint (geo-routing) with a great-arc fallback.

Plus – you don’t need to mess around with the reflection!