Proxy Generator - does such a tool exist?

[Mike Bromwich]

Hi

Our product can interact with a number of third party assemblies, as
long as the customer has purchased and installed these libraries. We
do not want to add references to these assemblies into our solution,
since this stops the product from running if the assemblies are not
present.

We could change our product to call the third-party assemblies using
reflection, but the interface exposed by the assemblies is complex and
this would be a very laborious and error-prone approach.

What we would like is a tool which we can point at an assembly, and
which would use reflection to generate a new assembly which exposes
the same interface but which calls the underlying assembly using
reflection. The output from this tool would be referenced by our
product, but if we call a method on a non-existent assembly this would
result in an exception rather than the product itself not loading.

Does such a tool exist?

Thanks

Mike

 

[Peter Morris]

That's a REALLY over engineered solution to a problem.

Do these 3rd party libraries all do the same thing, but just in different
ways? e.g. do they all calculate loan repayments or something?

 

[Mike Bromwich]

Hi Pete

Thanks for the reply. The third-party tools perform exports to various
formats - PDF, XLS etc. etc., but we do not know whether the client
will have each of the tools. The tools all have their own .NET APIs,
but we do not want to reference them in the product since the product
will the not even run if one of the tools is missing.

Being able to generate a 'proxy' assembly and reference this seemed
like a straightforward way to remove the dependency, without having to
resort to performing all the relevant invocations using reflection.

If such a tool existed, I was hoping we could just run it once for
each tool and then bind to the proxy - it seems like a very simple
rather than over-engineed. Essentially, it would just be late binding
- and a similar model to what VS does when referencing a Web Service.

Mike

 

[Peter Morris]

01: Have a generic interface in a shared assembly.

public interface IProducer
{
string Name { get; }
string FileExtension { get; }
void Produce(MyDocumentType doc, string fileName);
}

public interface IProducerProvider
{
void AddProducers(IList<IProducer> producers);
}



02: Create an assembly for each production target which doesn't actually use
the 3rd party tool. It should have a class in like so

public class PdfProducerProvider : IProducerProvider
{
public void AddProducers(IList<IProducer> producers)
{
if (3rd party tool not installed)
return;

dynamically load PdfProducer.dll
reflect over assembly, find all implementors of IProducer
create instance of IProducer and add to producers
}
}


03: Your app needs only to use the shared DLL
Dynamically load all DLLs in a specific folder ending with
"_ProducerProvider.dll" (to avoid loading the producer itself).
Find classes implementing IProducerProvider
Create an instance of it
Call AddProducers

 

[Mike Bromwich]

Thanks Pete

I'll try approach and see where I get to - although the interfaces to
the tools are very significantly different. For example, the PDF tool
(Ibex) takes XSL:FO markup, and the XLS tool (Spreadsheetgear) uses an
API covering rows, sheets, cells etc.

Mike

 

[Peter Morris]

You could still have all of the interfaces in the shared lib, have a single
class which checks for availability and sets its properties accordingly.


public static class PluginManager
{
public static IPdfProducer { get; private set; }
public static IXmlProducer { get; private set; }

PluginManager()
{
if (3rd party 1 installed)
Load your PdfProducerStub assembly;
etc
}

}