CODEWITHSUNDEEP
.netf#32bit-64bitunmanagedfsi
bugfoot
bugfoot

Reputation: 667

Identical F#.NET solution works in FSI under 32-bit OS, but not under 64-bit OS

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.

Upvotes: 1

Views: 146

Answers (1)

Baldrick
Baldrick

Reputation: 11840

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.

Upvotes: 1

Related Questions