How to find out where Assembly.Load(String) would load an assembly from without actually doing it?

This is the question:

I want to know where the assembly will be loaded from, but I don't want to actually load it. Can I do that? How?

If you read my previous post, you will already know the answer is NO. In general you can’t find out where the assembly will be loaded unless you load it.


Of course this does not prevent you from making a well educated guess based on the documented fusion probing behavior. But this guess won't be accurate all the time.


Or we can ask the question the other way:


Why do you need to know that?

Can you achieve your goal with alternative ways?


Comments (7)

  1. Unless trickery is involved, you would usually get the assembly from AppBasePath or PrivateBinPath,etc.

    So that should be enough for most of it.

  2. Henry Boehlert says:

    I’m creating a makefile (for use by ClearCase omake) out of a VS C#

    project file.

    In a script in the XSLT I’m using AssemblyName.GetAssemblyName to figure

    out if I need to create a /lib parameter for a reference.

    Maybe I’m totally WTF but it think I would be happy if someone points me to

    the GAC.Contains method somewhere.

    Can’t use devenv /rebuild because I’m using /win32res with some

    mandatory custom data for traceability. Furthermore, debug and release

    bits need to be separated.

    Desperately waiting for MSBuild, I guess.

  3. Well, how about my GAC API Managed Wrapper?

    Sample Managed GAC API Wrappers

    Specifically, QueryAssemblyInfo.

  4. Norman Diamond says:

    > Why do you need to know that?

    Oh that’s easy to answer. Or maybe only easy to nearly-answer, but here are two very very near-answers.

    1. Why did Raymond Chen blog about a way to do Unix’s "which" command in Windows? Was it because 30 years of experience with the "which" command in Unix showed how useless it was? Or because it is useful?

    2. There are some important programs that run under Windows and inspect the contents of ordinary executable files in sandboxes before letting the ordinary executable files actually run.

  5. Norman,

    Looking for exes is very static. The OS simply looks at the directories listed in %PATH% environment variable.

    Now imagine this:

    There is a switch. When the switch is turned on, the OS will look at some other places instead of %PATH%.

    Ok. There are more switches. When they are turned on the OS will do something different.

    Even the exe is not found in %PATH%, you can say I want the OS to try something else.

    Now how much "which" is useful?

  6. Norman Diamond says:

    It seems to me that the importance of the "which" command multiplies by a huge factor in that kind of situation.

    By the way this means a real "which" command not just one that looks at %PATH%. For example competent "which" commands on Unix look at aliases and other possible settings besides just $PATH, in order to report what the shell (or OS in your case) will really do.

  7. The problem is those factors are unknown until runtime. There is really nothing you can do.

Skip to main content