have IVF generate a genuine , VS2008-compatible DLL

[erik2055]

I have a VS2008 Solution with 2 projects in ti. P1 is a VB.NET project, in which I call a routine from a DLL that was generated by P2, which is IVF Fortran.
All compile well and run well together.
However, it is a nuisance to find out how to refer to the routines in the DLL from VB.NET. The DLL is put in P@'s output directory and I have to find out the (relative) path to it in the VB project.
I can add a reference to the DLL to P1, so P1 can easily find the DLL. But the, the DLL needs to be a "genuine .NET DLL", so i read on the Net, or else VS2008 won't find it (The Add Reference dialog | Projects tab is empty, and the Browse tab says the DLL is there but no good)
question:
How can I generate a fully .NET compatible DLL with IVF 11.0 ?

[ArturGuzik · Accepted solution]

Quoting - erik2055

How can I generate a fully .NET compatible DLL with IVF 11.0 ?

Eric,

you just can't (create managed code dll). To make your life easier you can:

(1) add dependency of your .Net project on your Fortran project
(2) use post-build events (Project->Properties->Build events) in the Fortran project to copy the Fortran dll to appropriate .Net folder (or any other place where your .Net projects looks for unmanaged code dll(s)).

Then changes and rebuilds handle the tasks automatically (and you can avoid terrible experience of debugging modified code using non-modified old version dll :-))

A.

[ArturGuzik]

And one more thing. You'll find this link to MSDN handy when dealing with copy/project relative paths etc.

A.

[erik2055]

Quoting - ArturGuzik

Eric,

you just can't (create managed code dll). To make your life easier you can:

(1) add dependency of your .Net project on your Fortran project
(2) use post-build events (Project->Properties->Build events) in the Fortran project to copy the Fortran dll to appropriate .Net folder (or any other place where your .Net projects looks for unmanaged code dll(s)).

Then changes and rebuilds handle the tasks automatically (and you can avoid terrible experience of debugging modified code using non-modified old version dll :-))

A.

Ok, but that is equivalent to setting the P2 output directory to some know location like C:

The point is, that I need to keep track of the location in two places: VS2008 Solution settings and the declare statement in the VB source:

Declare Sub DPBSVX Lib "BLABLAbindebugMyDll.dll" ( ByVal fact As String, ByVal uplo As String)


Anyway: I need not look further, I understand.
thnx

[erik2055]

Quoting - ArturGuzik

And one more thing. You'll find this link to MSDN handy when dealing with copy/project relative paths etc.

A.

Indeed ! great help

[ArturGuzik]

Quoting - erik2055

Declare Sub DPBSVX Lib "BLABLAbindebugMyDll.dll" ( ByVal fact As String, ByVal uplo As String)

You don't need to specify full path in Lib keyword for dll(s) located in the Windows system directories and also current working directory, I believe. So copying to appropriate location(s) (.Net Realese/Debug folders) eliminates the edit step.

You also have another option for importing dll, DLLImport which offers more control (at least that's what guys from MS are saying). example:

CharSet:=CharSet.Unicode, ExactSpelling:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Shared Function MoveFile( _
ByVal src As String, _
ByVal dst As String) _
As Boolean
' Leave the body of the function empty.
End Function

where you can specify calling convention (example using C, STDCALL) etc.

A.