Calling FORTRAN dll under VB.,net

[Earl_Geddes]

I have used VB 6 and FORTRAN for decades with VB the GUI and FORTRAN the calculation engine. I am quite knowledgable in that environment. But a new 64 bit computer and Win 7 has forced my development into VB.Net and Intel FORTRAN.

I have tried and tried to get VB.Net code, which is very easy in VS2008 to call an Intel FORTRAN dll but it just won't work. I can do it under a consol app, but not in a managed code .net environment.

Any suggestions for what I need to do?

I have tried the demo's on this site and cannot get those to work either. The error that I typically get says that the OS cannot "load" the dll because it is the wrong format. An error that I have never seen in the previous decades and I don;t know what it actually means and how to circumvent it.

Apparantly calling a dll under .net is not as simple as the old days.

[Steven_L_Intel1]

Well, mixing .NET and x64 code certainly is not simple. It should work if you build your DLL as a 32-bit DLL.

I can reproduce the problem and am trying to work it through...

[Earl_Geddes]

Thanks Steve - I have used your products almost as long as you have worked on them - all the way back to DEC. I knew that I could count on you.

I cannot get the example in the Intel samples to run. I've tried several times now. Consol example run. Same example converted to win32 does not run.

Dumpbin confirms that the dll is available and that it exports the proper symbols, but VB does not like the "format", which, as I said, is an error that is unqiue to this platform as I have never seen it before.

[abhimodak]

Hi

I think I had toiled through similar issue earlier. I am using WinXP64 with VS2005 and IVF11.1.065. So, my system is different but I think the issue is similar.

Just to mention the exact steps:-

(1) When I open the sample VB-Calls-Fortran (after unzipping the MixedLanguage), first there is a conversion wizard. After clicking through that, I get it loaded and then hit build. The build completes and starting it opens up the form. "Do it" then throws the format error.

(2) Next, I select Project-->Properties--> Compile-->Advanced Compile options --> Target CPU --> x86 (for the VB project). Build and it runs fine.

(3) Similarly, one can also get the x64 build. But correspondingly, Fortran project must be built with x64.

(4) Note that the sample uses FCALL.dll from the top-level FCALL directory. When x64 is built for Fortran, the file copying must be also be done. Then for theVB project, again select Properties--> Compile--> Advanced Compile Options --> target CPU -->x64.

(5) I have noticed that clean solution does not clean the VB exe. So, before moving from x86 to x64, I right click the VB project and clean the build. I make sure that file VBCallsFortran.exe is deleted from the \bin directory of the VB project. Then do the build with appropriate x** platform.

(6) Finally, I think since there is String passing the answer given by the x64 build is wrong. (a) x86 given 2,4,6,8 (b) x64 gives 2,0,0,0. May be calling convention is at fault here. I seem to recall that this issue has been addressed on the forum before.

Abhi

[abhimodak]

Hi

String passing is not the issue on x64. Fortran seems to be receiving the passed array elements as 1, 0, 2, 0. However (of course not exactly useful) passing individual array elements works.

Abhi

[abhimodak]

There is a KB article by Mr. Green here: http://software.intel.com/en-us/articles/visual-basic-passing-array-to-fortran-dll-in-x64/

Abhi

[Earl_Geddes]

Hi Abhi

Thanks for the note.

I have tried all of the examples that you mentioned. They all work as "console" apps, no problem, but not as Windows apps. It appears to have something to do with managed code and X64 as far as I can tell by tracing down the error code. From what I have read this error is caused by a DLL that is not properly setup for the system, but the MS help on this error is very broad and impossible to tell precisely what it means in my context.

So, thanks for the advise, but it hasn't helped.

Earl

[Earl_Geddes]

Update - I tried the VB - calls - FORTRAN again doing exactly what you suggest and it does work. You must follow that exact procedure however, because if you do what it says in the notes with the sample, it will not work!!

I'll work through this from that point and maybe get back.

[abhimodak]

Hi

May be Intel needs to update this sample (or its readme)?

In addition to alerting the users to ensure that VB project is the start up project and how to debug the unmanaged code, I think the crucial points missed are:

(a) the location of the Fortran dll,

(b) matching of x64 VB exe to x64 Fortran dll and x86 VB.exe to x86 Fortran dll, and

(c) the correct way of passing arrays from VB to Fortran.

While the first two are clearly what "one should know", I think the confusion is caused by setting of the output directory paths. Fortran dll built by the Win32 build comes to the "upper" level; but when the project settings are copied in the configuration manager, x64 project properties don't get the output directory property.

Since, the Declare Lib from VB needs the path for the dll as a constant expression, the path cannot be softwired. (I think DLLImport, the alternative to Declare, also needs a string const.) So the dll's name cannot be picked up from some textbox on the form... or can it be?)

VB project's advanced compile option button may not be too familiar with first timers and the fact that one needs to the clean solution may add to confusion.

Finally, my opinion is that (c) above must be included in the sample. The KB article by Mr. Green clearly states that the sample's way of passing the arrays "worked by fluke".

Abhi

[Steven_L_Intel1]

Yes, we'll take care of this. Thanks.