1

I have an F#.NET solution with one project in VS 2013 that contains some managed C#.NET and unmanaged C++ DLL references.

This solution runs perfectly in FSI under 32-bit Windows 7 Enterprise. However, if I copy everything in the solution to a computer with 64-bit Windows 8.1 OS, keeping all relative and absolute paths of the referenced DLLs, files etc. the same, FSI gives me

System.DllNotFoundException: Unable to load DLL 'dllName': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

error for unmanaged C++ DLL named dllName that is part of the solution, is copied, is there, is referenced.

dllName has both a 32-bit and a 64-bit versions under \x64 and \x86 folders. Both of them are referenced, are copied and are there. The project properties are the same on both the 32-bit OS and the 64-bit OS. I also tried all possible combinations for Configuration and Platform settings of Properties -> Debug as well as Configuration, Platform and Platform target settings of Properties -> Build under the 64-bit OS to no avail.

I guess somehow the FSI, which appears as Fsi.exe (32-bit) in Task Manager -> Processes in the 64-bit OS, but Fsi.exe in the 32-bit OS, is the culprit in messing up my 32-bit app in 64-bit environment without me touching any part of the solution.

bugfoot
  • 667
  • 7
  • 20
  • It is pretty unclear what you did to ensure that the operating system can find the DLL in that x86 subdirectory. And whether you took care of also deploying the dependent DLLs that this DLL needs, everybody always forgets to copy the CRT dependencies. Simplest way to diagnose this is by running SysInternals' Process Monitor. Towards the end of the trace you get, you'll see the program searching for the missing DLL and not finding it. – Hans Passant Nov 01 '14 at 12:31
  • @Hans Passant Thanks for the suggestion. Checked with Process Monitor, and it seemed fsi.exe tried to find the DLL everywhere (exotic places like C:\Users\Rebecca\AppData\Local\assembly\dl3\KYOX0B1Q.Z4R\76HH9QN1.6KW\eadfc563\00e04bbe_6b74cf01\, etc.) except where it actually was. So I copied the DLL to a folder it was looking for and now it works - not a stable solution I guess. However, I still don't understand what I need to do for fsi.exe to find the DLL where it actually is under the 64-bit OS. How come fsi.exe tries to look for it everywhere except where it is actually referenced? – bugfoot Nov 01 '14 at 19:58
  • Did you try setting _64-bit F# Interactive_ to true in Tools|Options|F# Tools|64-bit F# Interactive? On the 64bit system, after resetting FSI, the FSI process will then show as FsiAnyCPU.exe, not as Fsi.exe (32-bit) as in your example. – Marc Sigrist Nov 02 '14 at 13:42

1 Answers1

1

Late to the party I know, but for the benefit of future searchers:

I had this exact issue when my F# application dynamically loaded a mixed mode C++/CLI dll (with unmanaged DLL dependencies) from a share.

It worked fine in non-interactive, but failed to load the DLL in interactive.

The issue for me was shadow copying, which was not working for unmanaged dependencies of the DLL.

The solution was to switch off F# interactive shadow copying. The setting is under Tools->Options->F# tools->Shadow copy assemblies. If I set this to false, everything works fine.

Baldrick
  • 11,712
  • 2
  • 31
  • 35