Running a C# Windows Forms application on Windows 7 in Parallels 8 error

Question

I have written a pretty simple C# Windows Forms application, and a colleague wants to test it out on Windows 7 using Parallels 8, because he only has a Mac.

The problem is, when he starts it up using the EXE file in the debug folder, he gets this error:

Error starting OMAPI (Unable to load DLL 'libomapi.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)) Check the required .dll files are present the correct versions: OmApiNet.dll libomapi.dll

As you can see from the image below, the required DLL files are right there in the same folder, and if he takes this debug folder to a Windows PC it works fine, so it's definitely some sort of virtual machine or Parallels-specific problem.

How can I fix this problem?

I haven't really used virtual machines enough to know what the problem could be...

Superordinate

What format is the executable versus the libraries? Given it's IN the same folder it should find it so I'm wondering if it's really a bad format problem (32-bit vs 64-bit)? – Decor

You might also find it's an external dependancy problem, something on your parallels setup doesn't exist that does on your other setup, try using Dependency Walker - dependencywalker.com – Decor

I've seen some funny things happen if the project is compiled for AnyCPU but a dependent library is x86 and the destination OS is x64. – Syringa

Make sure all your dependend DLLs and your application are built with the same processor architecture (x86 or x64). Stay away from AnyCPU with virtual machines. – Alida

(Sorry for the late reply been away) Ah okay, I'll ask him what his Parallels setup is and I'll recompile with x86/x64 rather than AnyCPU and report back. Thanks all for the help so far. – Superordinate

His setup is Windows 8 64-bit on Parallels 8 on OSX 10.8.3 . I used Dependency Walker and it says it can't find IEShims.dll. I've googled this and it's apparently an Internet Explorer 8 dll and our winforms application does make use of the WebBrowser control (which in turn uses the internet explorer installation on the PC) so could this be the problem? He has the Internet Explorer that came with Windows 8 installed exactly the same as my non-virtual machine windows 8 64-bit does but could the problem lie there? – Superordinate

I also tried compiling it in an x86 profile etc. but we have many projects in this solution and it for some reason doesn't like some of them being changed to x86 so when I changed the main winforms gui project to x86 it doesn't build the solution. – Superordinate

@poncho: Unless some of your projects reference x64 libraries that do not have a x86 counterpart, your WinForms solution should build (unless you're overlooking something). x86 works under both environments but if you cannot target that platform in some of your projects, that's where your problem is. – Skardol

Have you checked to see whether libomapi.dll exists on that VM? When you get a DLL error, making sure the DLL is there is the first place to start. – Glabrous

I am using OSX with Parallels and Win8 for development every day; no problem. Create a console and a winform and whatnot simple and send him. If simple stuff works then there is no basic dotnet problem. Win8 comes with IE9, not necessarily compatible with IE8 on DLL level. This problem might be a sign of future problems recognised already now. – Xavler

Answer 1

it'd be interesting to run ProcMon on it and see what it's really doing to try and find the files.

Nadean

Answer 2

This is possibly more of a network drive issue. Have him copy that folder from the Y: drive (shared from his Mac) to the C: drive and run it again from there.

Dustup

Answer 3

It looks like your trying to run the application from a network share, in which the .NET platform forbids as its a security risk. Try copying the files to someplace else on the virtual machine such as C:\Temp.

Larval