.NET Application looking for DLLs in locale specific sub-folder -


my company have internal utility libraries containing things base services, useful extension methods etc.

i have re-written these ground , have packaged them nu-get packages, hosted on our internal network.

when i've added added nuget reference packages in project, application build, when debugging or running fail saying libraries cannot found. seems entirely @ random, , if re-build , re-deploy problem temporally fixed.

a colleague of mine managed narrow down problem running process monitor, , found application looking files in bin/en-gb/{mycompany.dllname}/{mycompany.dllname}.dll when file in bin/{mycompany.dllname}.dll, expect default.

so temporary fix, can add folder structure requires , able run application, having re-add folder structure , manually copy , paste dlls around after every clean/rebuild not long term solution. don't know:

  1. why works.
  2. what causing behavior.

i don't know whether issue utility libraries project, nuget package, or consuming project.

i realise helpful design .net feature, allowing locale specific versions of ddls, in situation not require them, , dll can be/is culture invariant.

any massively appreciated holding release of our new libraries.

there no mechanism in .net makes assemblies contain code in "en-gb" subdirectory that. ever used satellite assemblies, don't contain code, resources, , resourcemanager class probing.

the candidate kind of behavior improper appdomain.assemblyresolve event handler in application. event that's going run if assembly cannot found reason. search codebase "assemblyresolve", hovers near main() method.

a long-distance shot [assemblyculture] attribute. must "neutral" assemblies contains code. think might affect fusion probes when can't find assembly in normal location. should fixed, core problem still can't find assembly.

do watch out [assemblyversion], if deploy libraries nuget need app.exe.config <bindingredirect> update of library doesn't break app. never use, say, "1.0.*", causes misery.

and use fuslogvw.exe diagnose load failures this. if these hints don't solve problem show trace get.


Comments