.NET dynamically loading assembly

[ASB]

Using reflection you should be able to find the type in the assembly and use the type to invoke the method.

So something like [NB code is not tested - and you are likely to need some null tests due to reflection almost always returning null and not throwing when types etc not found]

Assembly assembly = Assembly.LoadFile("... assembly path ..");
Type methodHostType = assembly.GetType("... type name ...");
MethodInfo method = methodHostType.GetMethod("... MethodName ...", BindingFlags.Public | BindingFlags.Static);

object result = method.Invoke(null, ... params ...);

You may also want to look at loading this assembly into a separate app domain.

Hopefully that will point you in the right direction.

I know I could do it with reflection, but that's always a last resort for me.

I think I've probably done the best I simply can. But thanks.

[Jaws]

Using reflection you should be able to find the type in the assembly and use the type to invoke the method.

So something like [NB code is not tested - and you are likely to need some null tests due to reflection almost always returning null and not throwing when types etc not found]

Assembly assembly = Assembly.LoadFile("... assembly path ..");
Type methodHostType = assembly.GetType("... type name ...");
MethodInfo method = methodHostType.GetMethod("... MethodName ...", BindingFlags.Public | BindingFlags.Static);

object result = method.Invoke(null, ... params ...);

You may also want to look at loading this assembly into a separate app domain.

Hopefully that will point you in the right direction.

[ASB]

Sounds like a lot of fannying around, is there really no way to address the real issue of not getting the dll on your machine?

If not, why not?

No. It's licence and environment related. It accesses the whole world and requires assorted servers set up in a specific test configuration and all sorts of things.

So, I've dealt with it by producing a wrapper which makes the decisions so the main code can be the same and it is switchable by configuration.

My alternative was, in effect, to produce a DLL with the same types etc (which is what I wanted to do) but I couldn't figure a way of dynamiclly loading "real" or "simuator" thus this would only have been configurable at build time.

[jmo21]

Sounds like a lot of fannying around, is there really no way to address the real issue of not getting the dll on your machine?

If not, why not?

[ASB]

I have a 3rd party assembly I need to use. However I can't install it on my development machine for a variety of reasons.

What I was going to do was reference it but, for development, use activator.createinstance to create the types from a simulator I was planning to produce. They would obviously have the same signature.

Now I'm a bit stumped. A number of the methods are static and I haven't got a clue how to emulate these.

I would have a reference to the 3rd party DLL and my simulator and was planning to write something like:-

dim typeToUse as 3rdParty.Type

typeToUse = activator.createInstance"myEmulator.Type"

Problem is that a number of the methods I need to access are static.

e.g.

result = 3rdParty.Type.DoSomething

Any suggestions ??

Basically I just want to create an assembly with the same objects, methods (both static and instance) and load it dynamically to get access to the types.