IVF 9.1 and VB 2005 together under VS 2005

[Ismail_A_]

I have a solution that has two projects in it. One is a simple Fortran DLL project and the other one is a VB.NET 2005 Windows application.

I know that I can create a Fortran DLL and call it from VB.NET, but since they are part of the same solution, is there any way of embedding the Fortran code into the VB exe and just have one exe that has mixed language code in it? I'd like to be able to call Fortran functions directly from my VB project without using external DLLs.

[Steven_L_Intel1]

No, you cannot embed the code. You must have a separate DLL for the Fortran code. VB has no mechanism for linking in objects from other languages.

[Ismail_A_]

Steve,

Thanks for the fast response.

As I understand, I can build a common EXE or DLL in a VS solution where there is a C# and VB.NET projects.

My understanding is that I cannot build a single DLL or EXE from Fortran and VB. Does this mean that Fortran is not really .NET ready yet?

By the way, why isn't IVF in this list?
http://www.dotnetpowered.com/languages.aspx

[Steven_L_Intel1]

IVF is not a ".NET language". It generates native-mode, "unmanaged" code only. It DOES interoperate with .NET in various ways. Do not be confused by the .NET in the development environment name (which MS has now dropped.)

You will need to build a separate DLL for your Fortran code and place it in the same folder as your EXE. You should also specify that the Fortran DLL links against the "Multithreaded", non-debug version of the static run-time libraries to avoid having to distribute other DLLs.

[Ismail_A_]

I see.

Is there a plan to make IVF a managed, .NET language?

[Steven_L_Intel1]

No plans, and to be honest, we don't see much demand for this. We're focused instead on providing the advantages of Intel optimized code to .NET applications through the existing Fortran Module Wizard (Fortran calling .NET) and the upcoming COM Server Wizard (enables .NET to call Fortran code without using dllimport, but it doesn't eliminate the separate Fortran build.)

[info4]

From my point of view true integration with .NET (i.e. enabling it as a .NET language) would be great. Certainly more useful to me, than the development path you are taking.

Chris Green

[Ismail_A_]

Steve,

I would also expect the majority of Fortran usersjoin Chris and I on this issue. Did you conduct a survey among your users to learn how they want? I don't understand why Intel is not taking the route that makes sense, especially when both of its two major competitors already have a .NET Fortran.

We started doing heavy .NET development and I certainly would like to use a true .NET Fortran under VS 2005. If Intel will never be there, I'll have to look for alternatives.

My 2 cents.

Message Edited by ismail_alkan@fwc.com on 06-21-200603:54 AM

Message Edited by ismail_alkan@fwc.com on 06-21-200603:55 AM

[Nick2]

Compare your managed .NET app to your unmanaged VB6 or C++ app. It is my understanding that Fortran compiled into .NET is much much slower just as well than Fortran compiled into native/unmanaged code. Considering most Fortran apps are used for number crunching, moving to .NET is really not *that* good of an idea...I wanted a .NET compiler so I could just use the same executable on Linux (ok, ok, the VS integration thing seems nice too), but then I said, heck with it all, and decided to instead spend 15 extra minutes at the end of the development cycle and go build the Linux version with G95. What would your customer prefer?

[info4]

Sure thereare many applications where speed is of the essence and this is already catered for by native DLL linking as described above.

But by not having a facility to incorporate the Fortran into a neat, single, truly integrated.NET application is a significant shortcoming that is a lost benefit for many other, less speed critical applications. The COM wrapper idea is an awful, past generation,kludge. Why put effort into that when true integration .NET is possible as others appear to have done?

You've then gotthe best ofboth worlds.

Chris

[Steven_L_Intel1]

We've done several surveys and I've seen a disucssion of the issue in comp.lang.fortran. I've talked to many customers who use .NET. The overwhelming majority want to use Fortran's computational prowess with their .NET Web API or GUI. When asked about Fortran managed code, the silence is deafening.

I am not saying that NOBODY wants this. Clearly some do. But the apparent market failure of Lahey's .NET product shows that the demand is very small. Not to mention that the cost to develop such a product is enormous. We have LOTS of other things we'd rather do that we think more customers want.

I'd also point out that we'd have very little value to add to such an idea, as you'd be dependent on the Microsoft managed run-time for execution performance. You'd throw out all the work we've done on improving performance. There are also many language features we could not provide under .NET (no REAL(16), for example.)

Seriously, if that's what you want, go buy Lahey's product. Or Salford's.

But if you want the advantage of Intel Fortran performance and our full feature set, then do what a lot of our customers do and build Fortran DLLs and call them from your .NET language. We'll soon be reintroducing the COM Server Wizard from CVF that makes Fortran code "visible" in the .NET world. If you have IVF 9.1 and VS2005, let me know at steve.lionel at intel.com, and I can provide you with a preview copy.

[garyscott]

Hi, the product should be designed to offer the choice of producing native code or MSIL. Fortran is a general purpose programming language. There is no reason why choices should be limited. However, having said that, I would rather it produce Java byte code instead for better cross platform portability.

[Steven_L_Intel1]

Sure -in an ideal world with infinite resources, I'd agree. We've had more than a few requests for Xscale code for Windows CE devices too. I'm not against the idea or MSIL - in fact, I've been raising the issue internally on a regular basis. But we don't have infinite resources and we have to pick and choose our battles. For the issue of managed code, we don't have an existing compiler infrastructure to support that and the expense would be very high - not just in absolute terms but also in what wlse would NOT get done.

For the people who are using .NET, we do have a solution - as awkward as it may seem at times - but it does work. My personal opinion is that our efforts are better spent on things such as finihsing Fortran 2003 and looking at things such as Co-Array Fortran that leverage our existing expertise.

[garyscott]

I understand. I'm not intending to be critical (although I note that other vendors with far fewer apparent resources have made great accomplishments in this area even implementing large portions of F2k as part of the .net activity), just expressing my desires for the product. It's your decision as to what markets you want to target. I want to keep my interests in your consciousness, though.

[info4]

Ditto. I could not agree more and it would be a shame to see a compiler that I have used from in it various forms since Microsoft Fortran days fall behind in this important area.