You can use the reflection API to call methods, properties and fields of any class, including those that you've loaded from an assembly at runtime. This is what Eddy's pointed you at. However, reflection is slow, and also pretty cumbersome to write code for. If you know what methods you want to call, then that means you can define an interface, and if you're writing the assembly you're trying to load from (or people are writing them to an API you specify), you can make sure the class you try to load implements it. Put that interface in a library that both the main application and the external library can refer to (this can be actually in the application assembly in some cases), and make sure that the classes you want to interact with in the external assembly implement it. You can then cast the result of Activator.CreateInstance to the interface and call methods on the instance directly. There are several examples of plugin architectures (because that's what your close to) available on CP. Here's a simple example modified from a previous version of my LobbyClient (the current one loads plugins into a separate AppDomain which you probably aren't looking for):
public static IGameType LoadContent(String filename){
Assembly a = Assembly.LoadFrom(filename);
if(a == null) throw new GameLoadException("Assembly "+filename+" not found or not valid");
foreach(Module mod in a.GetLoadedModules()){
foreach(Type ty in mod.GetTypes()){
foreach(Type intf in ty.GetInterfaces()){
if(intf == typeof(IGameType)){
return (IGameType)System.Activator.CreateInstance(ty);
}
}
}
}
}
IGameType is specified somewhere that plugin classes can see it when you're writing plugins.
