Searching for types

  • Thread starter Thread starter Michael S.
  • Start date Start date
M

Michael S.

Hi there,

If I call "System.Type.GetType()", passing in the assembly-qualified name of
the type to search for, how can I go about controlling where .NET will look
for the assembly containing the type. Assuming I'm not using strong names
for instance (no GAC involved), and I pass the following string for example:

"SomeNamespacee.SomeDialog, SomeApp, Version=1.0.2896.22054,
Culture=neutral, PublicKeyToken=null"

I now want "System.Type.GetType()" to look for the "SomeApp" assembly in a
given folder that I can control at runtime (instead of or in addition to my
app's start-up folder). Thanks in advance.
 
Michael,

Calling GetType is going to use Fusion, which is a well-defined process
(you can look in the documentation to see exactly what the order is).

You can tell the CLR to look in additional subfolders by using the
<probing> element in the configuration file for the app. In this element,
you will specify the subdirectories to use in the privatePath attribute.
 
I now want "System.Type.GetType()" to look for the "SomeApp" assembly in a
given folder that I can control at runtime (instead of or in addition to my
app's start-up folder). Thanks in advance.

You can also first load the assembly from the location you want (using
Assembly.LoadFrom) and then call Assembly.GetType on that instance.


Mattias
 
Calling GetType is going to use Fusion, which is a well-defined process
(you can look in the documentation to see exactly what the order is).

You can tell the CLR to look in additional subfolders by using the
<probing> element in the configuration file for the app. In this element,
you will specify the subdirectories to use in the privatePath attribute.

Thanks for the info. After searching around a bit (for "fusion", "probing",
etc.), I seem to be on the right track now. Thanks again.
 
You can also first load the assembly from the location you want (using
Assembly.LoadFrom) and then call Assembly.GetType on that instance.

Thanks. Unfortunately, the assembly-qualified strings I need to call
"GetType()" on are arbitary strings I don't know about ahead of time. I want
my users to be able to set a search folder in my app (via "Tools ->
Options") and calls to "GetType()" will then look in that folder
automatically. I just need to instruct the system to look there accordingly.
 
Calling GetType is going to use Fusion, which is a well-defined
Thanks for the info. After searching around a bit (for "fusion",
"probing", etc.), I seem to be on the right track now. Thanks again.

I've been looking around for a while now and can't seem to find what I need.
The "probing" element for instance is only good for subdirectories of the
app's folder which won't do in my case. I've also looked at the "codebase"
element but it appears to have the same problem (for private assemblies
anyway). The situation is basically this. I'll be processing a file
containing assembly-qualified strings and I need to call "GetType()" on
these strings as previously noted. My users may be supplying the assemblies
that contain these types and they can be anywhere. I therefore want to
provide a "search folders" option via "Tools -> Options" where the user can
specify one or more search folders. When I later call "GetType()", the
search should now follow the usual .NET search locations but should also
include my user's "search folders" (or something similar to this - I'm still
working out the details). Is this possible? Thanks again.
 
Michael,

I think that in this case, you will have to manually load the assembly
into your app domain (the one you are running in, or another one, depending
on your program) and call the static LoadFile method on the Assembly to get
the CLR to load your assembly, then call GetType, passing the assembly
qualified name.
 
I think that in this case, you will have to manually load the assembly
into your app domain (the one you are running in, or another one,
depending on your program) and call the static LoadFile method on the
Assembly to get the CLR to load your assembly, then call GetType, passing
the assembly qualified name.

Yeah, it's looking that way. I'm digging into the docs now but may provide a
follow-up later if I can't unravel this myself. Thanks again for your help.
 
I think that in this case, you will have to manually load the assembly
Yeah, it's looking that way. I'm digging into the docs now but may provide
a follow-up later if I can't unravel this myself. Thanks again for your
help.

Ok, it seems like a needlessly complicated process but perhaps you can
confirm the following is safe and correct (or at least comment on the ".dll"
versus ".exe" situation in step 4 if you don't have the time). Given the
assembly-qualified name in my first post:

"SomeNamespace.SomeDialog, SomeApp, Version=1.0.2896.22054, Culture=neutral,
PublicKeyToken=null"

I would need to

1) Pass this to "System.Type.GetType()" as usual since I want to follow the
normal search path before my turning to my user's search paths. If
successful, great, otherwise look in my user's search paths as follows ...
2) Strip off the "type" from the assembly-qualified name which ends at the
first comma ((yielding "SomeNamespace.SomeDialog") and the "assembly name"
which is everything after it (if I understand the
"System.Type.AssemblyQualifiedName" docs correctly). I can't find any native
class that handles this for me.
3) Create an instance of the "AssemblyName" class, passing in the "assembly
name" from step 2 above (i.e.,. "SomeApp, Version=1.0.2896.22054,
Culture=neutral, PublicKeyToken=null")
4) Append "AssemblyName.Name" from step 3 above (yielding "SomeApp") to the
end of my user's first search path. Append an ".exe" extension and pass this
to "Assembly.LoadFile()" or "Assembly.LoadFrom()" (I'm not quite sure which
but am still investigating - comments?). If successful, goto step 5.
Otherwise retry this step using a ".dll" extension instead. How do you know
what (if any) extension you should use however or even what order to check
first (e.g., ".dll" versus ".exe" - there may be two such files in the same
folder). There's no extension in an assembly-qualified name in any case so
I'm just guessing here. Where's the formal rule for this.
5) If step 4 is successful, invoke "Assembly.GetType()", passing the "type"
retrieved in step 2 above ("SomeNamespace.SomeDialog" in this case). If
successful, great. Otherwise repeat steps 4 and 5 for the user's remaining
search paths.

Is this safe and reliable assuming no easier (native) method exists (which I
can't seem to find). Thanks again.
 
Back
Top