I'm not sure if I feel sorry for this.
-
But you can consider it a Coding Confessional.
My application's code resides in c:\app. Another app resides in c:\urp. A crapload of .net assemblies reside 4 subdirectories deep in c:\urp. My app loads an assembly in c:\urp\x\y\z\omg. That assembly references about a dozen other ones that also live in omg; they are all namespaced foo.whatever or bar.whatever. Since my app is in Progress, my source is in c:app, but the executable is in c:\progress\bin. My DLL wouldn't load due to versioning issues I've previously documented. I enabled the fusion assembly binding viewer and noticed that, depending on whether the assembly namespace was in foo or bar, the appbase would be either in c:\urp...omg or c:\progress\bin. That seems like a pretty big
in itself, but I need to load those assemblies. Judicious use of the <probing> element in c:\progress\bin\progress.exe.config got the foo assemblies to load, but the bar assemblies wouldn't load, even with the probing element set to look in the omg directory: the system refuses to load them since they're not in the appBase. I spent an hour trying to work around that--if anyone's got any brilliant ideas I'd love to hear them--before telling the loader to FOAD and used mklink /D to make omg appear to be a subdirectory of c:\progress\bin. All of a sudden 6 of the 10 assemblies that wouldn't load now do.I'd love to know why some assemblies wind up with a different appbase than others, when they're all in the same directory.
-
This post is deleted!
-
I'd probably start here, and then check for caching from your IDE. DLLs like to not get updated like they are supposed to in a variety of scenarios when you have this soup going on.
-
DLL hell is where old version of ANSI.SYS go to die.
-
Nuke it from orbit and start over at the architecture level sounds like the only solution.
-
There's only one version of the DLL on that system. Also this is runtime; no IDE involved.
-
WHAAAAARGARBL.
I tried to use a bindingRedirect: the DLL my app loads is built against 1.0.0.0 of the DLL in c:\urp...omg (it was built on a different machine, against an older version), but what I have is 1.1.0.0. I managed to get this to work for nearly all the DLLs...except one. I'm not sure if there's a recursive dependency I need to redirect away, because the Fusion logger first said 1.0 and 1.1 have different public key tokens. So I took the attribute off the dependentAssembly element...and now it looks like it's ignoring my redirect because the log says the DLL failed to load because of a minor version mismatch! WHY'S IT NOT READING THE APPCONFIG FOR ONE DLL!?!? Or more likely, what's the real problem?
Everyone else trying to do this kind of thing is having build-time problems--meaning that SO and the like aren't helpful. I've already got everything built, but I can't compile a version of this one DLL against every version of the Urp app, so I need to get this bindingRedirect thing to work.
-
Shit. You cannot use a bindingRedirect against an assembly who's public key token has changed, which I thought was going to be the case. SO seems to have some totally minimal example that claims to get around that using Assembly.LoadFrom and the AssemblyResolve event--it looks like that gets raised when a binding fails, and you can add a delegate and try to, I guess, manually load the version of the DLL you want.
Oh, this should be fun.
-
Of the dozen assemblies I was interested in, they changed the public key on two or so.
WTF. I mean seriously,
DLL Hell - Wikipedia
