By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,987 Members | 1,015 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,987 IT Pros & Developers. It's quick & easy.

Create an object via reflection without knowing the assembly

P: 81
Hey all,
I have a bit of peculiar problem. I need to create an instance of a class, but I do not know which assembly that class belongs to. I do know it is from an assembly loaded within the app domain though. I was hoping I could have it work in the following way:
Given a classpath, attempt to create the object from one of the assemblies currently loaded in the app domain.

Any way of doing this?

Cheers,
Nelson
Feb 6 '09 #1
Share this Question
Share on Google+
10 Replies


Plater
Expert 5K+
P: 7,872
Can't you open an assembly by a class path?
Or maybe you can open up the collection of assemblies and search for the class inside them?
Feb 6 '09 #2

P: 81
hmm interesting. I'm not sure how to do that, or that I could even do that!
Do you know how that works? I'll see what I can find.
Thanks,
Cheers
Feb 6 '09 #3

Plater
Expert 5K+
P: 7,872
Well what do you mean by class path?
Are you saying you know "System.Net.Sockets.Socket" and want to create an instance of Socket, but aren't sure what dll/assembly to open?
You can use the Type class to create an instace that way
Feb 6 '09 #4

P: 81
I have a framework that loads other modules we also build. So the class path I have is not a part of mscorelib, or a part of the current executing assembly. However I know the assembly will be loaded within the app domain. So I need a way of going through the assemblies of my current app domain (custom ones really), and seeing if I can create an instance of the class.

ie:
Project A has namespace A.B.C

Project B get s a string that says "A.B.C". Project B then needs to create an instance of "A.B.C", but does not know which assembly it belongs too.
Feb 6 '09 #5

Plater
Expert 5K+
P: 7,872
Well the Type class can be used to create an object from a string "A.B.C", but I think the assembly were "A.B.C" is located has to be in the build.
Unless you "open" it with the Assembly class and load it out of there.

This sounds a lot like plugin developement, I think Balabaster has more experiance doing this and might of better help.
Feb 6 '09 #6

vekipeki
Expert 100+
P: 229
If your "class path" is equal or somehow related to the actual assembly name (.dll name), then you can load it using Assembly.Load - just pass the full path to the assembly and you're there.

If you want to get a list of currently loaded assemblies (but they have to be loaded, i.e. already accessed by you running assembly!), you can use:

Expand|Select|Wrap|Line Numbers
  1. Assembly[] listOfAssemblies =
  2.      AppDomain.CurrentDomain.GetAssemblies();
  3.  
Note that if your assembly is already loaded, then you have already referenced it somewhere, so loading it using Assembly.Load is a more general way to do it (the way to go when using "plugin" assemblies, as Plater said). Try to google for ".net plugin" and you'll get some examples.
Feb 8 '09 #7

P: 81
Correct, this is a plugin framework piece that I'm working on. I can't just use the standard load this directory because we will have more then 1 directory that needs to be loaded.

That being said, is it more efficient in .NET to actually load all the dlls at once, or to use the assembly resolve event, and when it doesn't find a dll, you tell the event what directories to look in, and it loads it then? In this application, some dll's won't even be used unless a user clicks on a certain button, so why load it ahead of time? But if that is the best approach, let me know.

Thanks,
Nelson
Feb 9 '09 #8

P: 81
Does anyone know what the performance implications of this are?
Feb 9 '09 #9

vekipeki
Expert 100+
P: 229
You can only unload assemblies if they are running in a separate app domain (http://msdn.microsoft.com/en-us/libr...01(VS.80).aspx) - so, if you're just loading them using Assembly.Load, they will remain loaded during entire application lifetime.

You could certainly load them only when they are needed (lazy init). If there is several assemblies but you expect only some of them to be loaded, this will use less memory.

You can always expect a short delay the first time an assembly is accessed, even if it is already referenced in your exe, so loading it using Assembly.Load shouldn't make a greater difference (but there is a delay on load, so you can make a quick performance test app to see if you consider it to be annoying).

You can find samples for this (e.g. http://www.codeproject.com/KB/cs/Ass...ppdomains.aspx).
Feb 10 '09 #10

P: 81
Awesome thanks. This is what I had assumed. Thanks for the confirmation.
Feb 10 '09 #11

Post your reply

Sign in to post your reply or Sign up for a free account.