Calling dll from Excel CVF/IVF

[sabur]

I just recently purchased IVF 9.1 PRO and VS 2005.

I have searched this forum and tried googling but I still cannot solve the following problem:

I have a CVF 5 dll that is called from an Excel macro. I'm trying to port this to IVF 9.1. The dll is not that large so I simply created a new dll application in IVF and cut and pasted the source code from CVF to IVF. I created a new folder for the IVF version of this dll and changed the project name slightly to avoid confusion with names.I was able to get the build process to work without too much trouble (boy did that feel good). I then went through the Excel code and changed the paths and names in my "Declare" statements.

When I run the Excel code it comes to the first Call statement that needs the dll and I geta "Run-time error53" and a file not found message.

I have taken great pains to make sure the path/file namesin the Declare statements are correct. I originallyopened upthe properties window for the dll in Windows (XP SP2) andcut and pasted the path intotheExcel Declare line and then of coursetyped in the dll's name. I havecut and pasted both thepath/file name in the error message and the path/file namein my Declare statements, put them side by side in a text editor and compared them. I don't see any difference.

One other thing I did which may help narrow things down. I copied the CVF dll and pasted it in the IVF debug directory and changed the name to match the one I'm using in IVF. It successfully got past the first call to the dll without complaining. It hung up on the second one; a different subroutine in the dll but I"ll deal with that later. I'd just like to get the Excel code tofind the IVF version of the dll. Seems there's something I need to do on the IVF side. I'm using the same computer for both versions.

Keep in mind I'm just an engineer who knows how to program a little in FORTRAN. All this Visual Studio environment stuff is still a little fuzzy.

Thanks

Mike

[Steven_L_Intel1]

What does Dependency Walker have to say about the DLL on the system where it doesn't work?

[darkos]

Quoting - sabur

Steve etal,

The saga continues

Current situation:

The main installations of IVF 9.1 and Microsoft Studio 2005(? whatever the latest one is) are on a Dell 600m laptop with Windows XP SP 2 Home Edition. Things are working okay there.

Trying to redistribute on two other machines:

1st machine: Dell Desktop with Windows 2003 Pro SP 4. I can get the debug dll version to work (and yes I had to temporarily copy those *mdd.dll files to do this, just to see if I could get something to work) but so far not the release version; something to do with concatenating strings. (Btw, the release version seems to "find" the dlls okay on this machine.)

2nd machinge: Dell Desktop with Windows XP SP 2 Pro Edition. Can't get either debug or release version to work. Keep getting a "run time error 48" message for both verstions and it says it can't find my executable (C22DATA91.DLL). After a lot of fiddling and googling and Dependancy Walker"ing" this is what I have come up with. I copied the directory that contains my debug executable dll and supporting dlls from the "1st machine"(wherethe debugversionworks) tothe "2ndmachine". When I use Dep Walker on C22DATA91.DLLI get the following message onmachine 2 but NOT on machine 1 (orthe laptop for that matter):

Error: The Side-by-Side configuration information in "c:cell22fortran91c22data91c22data91 eleaseC22DATA91.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001)

Same thing for the release version. I do NOT have the Intel FORTRAN or Microsoft Studio 2005 installed on machines 1 or 2. I do haveCVF 6(?) installed on machine 1 though ifthat somehow might make a difference.

Sigh

Mike

Hi sabur,

I get the same problems on my DLL exactly as you explain in this thread. This specific problem you are facing now is due to the incorrect manifest in your DLL. On MSDN somebody suggested to turn off the MANIFEST. This solution did not work for me, but perhaps it will work for you. You select the DLL of your interest in IVF and go to Properties. Go to Linker and than to Manifest File. There you can switch it off. This is will stop Dependency Walker giving you the problem, but I still can not run my DLL. All of my DLLs are present in the application folder but still no luck. Let me know if you have found a workarround for your problem.

Darko

[darkos]

Quoting - darkos

Hi sabur,

I get the same problems on my DLL exactly as you explain in this thread. This specific problem you are facing now is due to the incorrect manifest in your DLL. On MSDN somebody suggested to turn off the MANIFEST. This solution did not work for me, but perhaps it will work for you. You select the DLL of your interest in IVF and go to Properties. Go to Linker and than to Manifest File. There you can switch it off. This is will stop Dependency Walker giving you the problem, but I still can not run my DLL. All of my DLLs are present in the application folder but still no luck. Let me know if you have found a workarround for your problem.

Darko

Hi sabur,

Darko again. I think I got it, but this has nothing to do with FORTRAN. Actually if you want to use VS compiled product on a machine that does not have VS you will have to install a package called vcredist_x86.exe. Further, some machines in combination with some programs might require a .NET Framework installation. This definitly solved my issue. Hope this helps.

Best wishes,

Darko

[DavidWhite]

Quoting - Steve Lionel (Intel)

I also can't figure out what is giving you a dependency on MSJAVA.DLL, etc...

Steve,

There is a flawed MSHTML.DLL which is on some systems which flags an erroneous call to MSJAVA.DLL. In some of my apps I have had to get a copy of MSJAVA.DLL to solve this problem. (even thoughMicrosofts license to use Java has expired)

I think there are comments about this on the Dependency Walker site.

David

[sabur]

Quoting - darkos

Hi sabur,

Darko again. I think I got it, but this has nothing to do with FORTRAN. Actually if you want to use VS compiled product on a machine that does not have VS you will have to install a package called vcredist_x86.exe. Further, some machines in combination with some programs might require a .NET Framework installation. This definitly solved my issue. Hope this helps.

Best wishes,

Darko

Darko,

Ah yes, I was searching the forum and came across this 2006 thread of mine and was surprised to see that someone had responded to it recently.

And you'reright. A while after I "abandoned" the thread I did discovered while googling, in some faraway hidden niche of the Internet, some reference to "vcredist_x86.exe" and discovered what you did; one needs to run this file on the other machine if that machine does not have Visual Studio installed in order to run Fortran executables along with the Fortran dlls needed to run on other machines that do not have the Fortran compiler installed.

Now with the latest Intel Fortran version (10(?) on up), VS is incorporated such that one does not need to buy a separate version of VS studio to install on you development machine so I would guess that if one takes this route (buy and use latest Intel Fortran version without installing separate VS) that one would not need to use "vcredist_x86.exe".

However, the VS that comes with the latest Intel Fortran is a bit stripped down and youcan still install a full blown separate version of Visual Studio along with the latest Intel Fortran and get the full "benefits" of VS. And I have little to no idea what most of those benefits are. One that I'm pretty sure about though is that with the full-blown version of VS you can compile C/C++ codes along with other languages. Right now I'm dealing with mixed-language issues and I need to work with a small C code so I need (feel free to correct me if I'm wrong anyone) the full blown separate version of Visual Studio, whichwasn'ta problem since I already had a copy (VS ver 2005) that I needed to buywhen I bought Intel Visual Fortan ver 9.0.

Mike

[Steven_L_Intel1]

You still need to install the Visual C++ resistributables on systems where you run Fortran executables or DLLs linked to the DLL libraries. You also need to provide the Fortran DLLs - we are working on a redistributable installer for those.

[sabur]

Quoting - Steve Lionel (Intel)

You still need to install the Visual C++ resistributables on systems where you run Fortran executables or DLLs linked to the DLL libraries. You also need to provide the Fortran DLLs - we are working on a redistributable installer for those.

So, even with IVF 10/11 (for which you don't need to buy and install a separate Visual Studio package as I understand it) you still have to install Visual C++ redistributables on other non Visual Studio systems?Do thefile(s) necessary to do this come with IVF version 10 and above?

[sabur]

Quoting - Steve Lionel (Intel)

You still need to install the Visual C++ resistributables on systems where you run Fortran executables or DLLs linked to the DLL libraries. You also need to provide the Fortran DLLs - we are working on a redistributable installer for those.

So, even with IVF 10/11 (for which you don't need to buy and install a separate Visual Studio package as I understand it) you still have to install Visual C++ redistributables on other non Visual Studio systems?Do thefile(s) necessary to do this come with IVF version 10 and above?

[Steven_L_Intel1]

This is no different than if you were using Microsoft Visual C++. If your Fortran application is linked to the DLL libraries, you will need the MSVC and the Fortran DLLs on other systems. The MSVC redistributable package does not come with IVF - you download it free from Microsoft. There is a different installer depending on which Visual Studio version you're using.

[sabur]

Quoting - Steve Lionel (Intel)

This is no different than if you were using Microsoft Visual C++. If your Fortran application is linked to the DLL libraries, you will need the MSVC and the Fortran DLLs on other systems. The MSVC redistributable package does not come with IVF - you download it free from Microsoft. There is a different installer depending on which Visual Studio version you're using.

Okay. I'll keep that in mind. BTW, I've noticed that this thread seems to have a relatively high number of views - around 9700. Any idea where this ranks in terms of "Views"? Is there a way to find thread statistics like this that I'm not seeing?

[Steven_L_Intel1]

It does seem to be high - I'm not sure how much confidence to put in the count. Statistics on threads in general are internal use only.

[DavidWhite]

Quoting - Steve Lionel (Intel)

This is no different than if you were using Microsoft Visual C++. If your Fortran application is linked to the DLL libraries, you will need the MSVC and the Fortran DLLs on other systems. The MSVC redistributable package does not come with IVF - you download it free from Microsoft. There is a different installer depending on which Visual Studio version you're using.

By using /libs:static in my compiles, I have managed to be able to distribute my Excel DLL apps without too much problems. Before I did this, I had to distribute the msvcr*.dll and associatedmanifest file. I now distribute only the DLL which is installed in the application folder, which I add to the PATH. I also put an .xla interface into the XLSTART folder. This works better than the EXcel Addins folder, which results in hardcoded paths to the users Addins folder, which fail when the spreadsheet is shared with other users.

If I get a chance, I will try to develop a simple .xla interface and associated fortan DLL project and post it here as an example. I am distrubuting 3 Excel / DLL applications to about 150 users globally within our company, and it seems to be working OK. I just hope that as we transition to Office 2007 later this year and perhaps Vista next year, I won't have a too rocky migration path.

David

[DavidWhite]

Here is my demo project for linking to Excel (see attached zip file)

ExcelDLL.dll needs to be placed somewhere on the PATH.

ExcelDLL.xla needs to be installed in C:Dcocuments and settingsUSERIDApplication DataMicrosoftExcelXLSTART instead of the AddIns folder, otherwise workbooks shared with other users will have unresolved links.

Use ExcellDLL Test.xls to test the functions.

As far as I have observed, no other files need to be installed on other users machines.

Regards,

David

[Bin_X_]

I got the the run-time error 53 too. My situation is: i can debug the code from VS 2012/IVF with IMSL (e.g., F5) and my dll works fine in the case. BUT if I run the Excel VBA directly, i got "runtime error 53". Any one know why? Thanks

[Steven_L_Intel1]

That's the generic error that VB/VBA gives if it can't load the DLL. It won't tell you the real reason. Are you using 32-bit or 64-bit Excel?

[Bin_X_]

Steve,

I am using Excel 2013 32-bit. Vs2012, intel fortran 2015 (ia32) with IMSL. I can run the code in debug mode (such as: F5 in VS 2012 by attaching Excel for debugging). But , when I run the code from Excel, i got run-time error 53 -:(  Pls help

Thx

[Bin_X_]

Strange thing is that: if I disable the calling for IMSL, everything good. If i call IMSL function, I can only run the code from VS by pressing F5 and attaching Excel) -:( 

[FortranFan]

Bin X., does your code have a dependency on a run-time DLL library from IMSL?  If yes, is it available somewhere in your path when you "run Excel VBA directly"?

[Steven_L_Intel1]

The IMSL DLL should be in PATH in a normal install.

[Bin_X_]

yes, IMSL dll is in the PATH. So, anyone know what could be the problem? Thx

>>>>>>Strange thing is that: if I disable the calling for IMSL, everything good. If i call IMSL function, I can only run the code from VS by pressing F5 and attaching Excel) -:( <<<<<<<<<<<

[Bin_X_]

The dependency walker  told me i am missing something? Attached figure. Can any one help me on this? I am new to this -:)