Known causes of FileNotFoundException

Dec 15, 2014 at 9:19 PM

First, I'd like to thank you for your great work on this lib! (and on LZ4 too, I use both ;)

Since an unresolved assembly manifests itself as a FileNotFoundException, I'd like to know if you have a list of common pitfalls/things to check for when using LibZ, that you may have encountered in the past?

I'm asking this, because a user of my lib opened an issue related to LibZ that I'm unable to reproduce. And it looks like a fairly standard project type to me. I'm using v1.1.0.2 to inject a mixed mode assembly in both x86 and x64 versions inside an AnyCPU assembly. I'm looking for any guidance that would help me reproduce/fix the user's problem.

Dec 15, 2014 at 10:13 PM
I would start with turning Trace on and telling you user to send you all the trace he can get. The mixed modes assemblies are saved to disk first as .NET is unable to load them (MixedMode ones) straight from memory. It saves them in Temp folder so there might be some security issues (machine is configured so it cannot execute from Temp?). There might be also dependency on Win32 assembly from you MixedMode assembly. This may manifest itself like you assembly cannot be found while, in fact, it's Win32 dependency is missing.

Anyway, I would definitely start with trace.

Note: to minimize dependencies LibZ sends traces with Trace class, which, I believe, uses OutputDebugString so he needs application which can intercept those (I usually use TraceTool).
Dec 15, 2014 at 10:46 PM
Thanks for the info, I didn't realize a missing native dependency could cause a FileNotFoundException. I just assumed the library simply wasn't being dumped to the temp directory, given the exception.

The mixed-mode library depends on the C++ runtime, and the user has a lower VS version than mine, so it's fairly possible he doesn't have the required redistributable package on his system. I'll try to figure it out.
Dec 23, 2014 at 11:03 PM
FYI, this was caused by a dependency on the VC++ 2013 redistributable package, which was missing on the user's environment.

Turns out that:
  • This package is not included in Windows Updates
  • There's no way to statically link to the runtime libs when using C++/CLI (with the /clr switch)
Which basically means... that there's no solution other than relying on the redistributable or including the runtime dlls along with the mixed-mode assembly.

I've found out that if I copy msvcr120.dll to the LibZ temp directory (the one with the md5 name), then it gets picked up. I suppose I could make a modified LibZ version that would inject/load native dlls while preserving their names, but I don't know if it's worth the effort, given it's not the best solution overall...