468,168 Members | 1,514 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,168 developers. It's quick & easy.

Dynamically Loading Assembly and Accessing its Types (namespaces are different)

Using 3.5, I am stuck in attempting to:

1. Dynamically load an assembly
2. Instantiate a class from that assembly (the client code is in a different
namespace than the namespace of the dynamically loaded assembly)

so far so good (per my code below)... but here is where I'm getting hung up:
3. Call methods of that type (see comments in my code)

If the types in the dynamically loaded assembly were in the same namespace
as the namespace of the code that does the loading, then life would be good.
I could just define an interface and implement it in the dynamically loaded
type. Then the client code could operate on the loaded type as its interface
type. But the namespaces are different (and they need to stay different -
and there cannot be a project reference to the dynamically loaded type's
project).

How do I get around that? How can I call methods of the type when (1) the
client code is in a different namespace and (2) the type gets loaded at
runtime - thus no ability to cast to the necessary type?

//************************************************** ***********************
string assemblyName = "CompanyNameHere.CopyFileInstaller";
string typeName = "CompanyNameHere.Installers.CopyFileInstaller" ; //
includes namespace

System.Reflection.Assembly loadedAssembly =
System.Reflection.Assembly.Load(assemblyName);

Type theType = null;
theType = loadedAssembly.GetType(typeName);

object instance = null; // ultimately I don't want an object type here if
possible
if (theType != null)
{
instance = Activator.CreateInstance(theType); // this works.

// ??? what goes here so I can call methods of the CopyFileInstaller type?
// instance is of object - and I don't know how to cast to the Type
of theType.
// That type is defined a different namespace than this executing
code
// and that namespace is located in an assembly loaded only at
runtime,
// so I can't just set a project reference...
}
//************************************************** ***********************

Thanks!

- "Smithers"
Aug 3 '07 #1
2 2788
Hi,

"Smithers" <A@B.comwrote in message
news:uZ**************@TK2MSFTNGP04.phx.gbl...
Using 3.5, I am stuck in attempting to:

1. Dynamically load an assembly
2. Instantiate a class from that assembly (the client code is in a
different namespace than the namespace of the dynamically loaded assembly)

so far so good (per my code below)... but here is where I'm getting hung
up:
3. Call methods of that type (see comments in my code)

It has nothing to do with the namespace with rather the definition of the
interfaces of those types dynamically loaded.
If those types implement an interface known by the calling code you are ok,
you can cast the CreateInstance to the correct type.
For example if any type implement System.Windows.Form you can access it.

A possible solution in your case is to define a set of interfaces in a
separate DLL that both the calling code as the called code types implement.
Then you can access them using these interfaces.
Aug 3 '07 #2
RE:
<< A possible solution in your case is to define a set of interfaces in a
separate DLL that both the calling code as the called code types implement.
Then you can access them using these interfaces.>>

I just did this and it works beautifully.

A quick followup question:
Is doing the above considered in any way to be a "hack" or somehow a "bad
thing"?

While it creates another project and .dll to maintain (as little as that
maintenance is over time), it seems to be *less* of a hack than using
Reflection (which I also got to work) - at least in my "plugin application".
I'd be interested in your thoughts on this perspective.

Thanks again.

Aug 5 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Bruce W. Roeser | last post: by
1 post views Thread by mirage83 | last post: by
reply views Thread by kamranasdasdas | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.