Resolve libraries path used by .NET application

Question

I want to find the full path for libraries used in a given .NET application.

These are both, referenced assemblies (obtained as AssemblyNames) and P/Invoke/DllImported functions (obtained as just the dll name).

So basically I'm searching for the content of these two methods, where executablePath is the path of that third party .NET application which can be completely different from my program.

static string ResolveAssemblyPath(AssemblyName name, string executablePath)
{
    // ...
}

static string ResolveDllPath(string name, string executablePath)
{
    // ...
}

It's important that these found libraries do not execute any code in the process of determining their full path! (DllMain, module initializers, ...)

Is that even possible in every case? It's not an option to guess wrong.

Oh and everything should be done under _.NET4_ client profile. — ordag, Nov 19 '11 at 19:31
any reason you don't use reflector or similar tool to disassemble their content ? — Yahia, Nov 19 '11 at 19:32
@Yahia - that does give my just something like `"kernel32.dll"` or `"{mscorlib, Version=4.0.0.0, [...]}"`, I need the full path to that libs. _(And these are just examples which could be hard coded ...)_ — ordag, Nov 19 '11 at 19:34
@ Ritch Melton - In that direction, but also for resolution of native dlls, and it should really not execute any other code, and of course programmatically here ;-) — ordag, Nov 19 '11 at 19:41
@ordag I mean just disassemble the respective methods to see how they implemented... — Yahia, Nov 19 '11 at 20:16
May be you want to check this answer from Hans http://stackoverflow.com/questions/2411736/p-invoke-dynamic-dll-search-path — Surjit Samra, Nov 19 '11 at 20:19

score 1 · Answer 1 · answered Nov 19 '11 at 20:04

It's possible but you need to replicate the search order of the windows loader, which differs for native and managed modules, and even windows versions. I've seen it posted in different levels of details in various blogs, though I have none of them at hand. It also seems to be documented in the MSDN, so see if that works for you.

Anyways if it's not an option to guess wrong you got a problem because any future windows version can extend or modify the search order, so you won't be upwards-compatible to future windows versions.

Also there are rules to redirect the windows loader, eg. through the manifest or the registry, which you would also have to replicate if you want exact coverage.

Resolve libraries path used by .NET application

1 Answers1