- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have used IVF and VS to make VB code that calls a FORTRAN DLL, for decades, all the way up to Win8.1. I just got a new computer (with Win10) and installed IVF and VS2019 and now none of my solutions work anymore. The VS2019 install is new as I used VS 2017 previously. I assume that IVF hasn't changed much since then. I load the solutions (VB and FORTRAN) clean, rebuild, and run.
In each and every case I get error "An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
I have changed nothing (to my knowledge) and I have tried so many things that I can't enumerate them all.
A web app (no FORTRAN) done on my old computer works fine, loads and runs and publishes just fine. So it is clearly something to do with the FORTRAN DLLs.
Does anyone have some suggestions on how to resolve this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Going back to what I wrote earlier, you probably have a 32-bit VB calling a 64-bit DLL (or vice-versa.) I suggest, in the VB project, setting the CPU type to either 32 or 64 bit, matching that of the DLL.
The typical way of dealing with the path issue is to copy the DLL into the same folder as the VB executable.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The usual cause of that error is trying to load a 64-bit DLL from a 32-bit VB. I assume you are seeing this error when the VB app runs. I just tried a mixed VB-Fortran project with VS2019 and the new oneAPI compiler, and it worked fine. Make sure you aren't building a "x64" configuration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve
First let me say how much I appreciate your support of FORTRAN (my first programming language.) I believe that your career goes all the way back to DEC. Congratulations on a remarkable career.
I think that I worked through many of the problems that popped up when I moved computers and OS (8.1 to 10). Most were due to defaults that caused problems, and most I was able to resolve. But now I get one that I have never seen before and don't understand.
I get no compile or link errors, but when I try to run within the debugger I get:
"Unable to start program XXX.exe. Interop debugging is not supported."
Any ideas here?
And thanks again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve
I am back to a similar problem. When set to X64, the linker fails with "Error fatal error LNK1561: entry point must be defined LINK"
This is not a requirement in Win32!?
Can I just use an empty "Main" subroutine as an entry point?
So I either get a DLL than windows does not recognize or a link error that is entirely a new requirement.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A couple of things here.
First, to debug a DLL project, where the executable isn't in the solution (Excel, for example), you need to put the path to the EXE in the DLL project's Debugging > Command property.
Second, when you have a managed code project (VB for example), you have to enable "native code debugging" in the managed code project. In a VB project, this is on the Debug property page.
I haven't seen the "interop debugging" message, but some web searches provide some interesting links: Mixed mode debugging for x64 processes is only supported when using Microsoft.NET Framework 4 or greater - Visual Studio | Microsoft Docs , Debug in Mixed Mode - Visual Studio | Microsoft Docs
Does this help?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve,
I am not really a "beginner as the listing says. I was forced to reapply, I guess my original account must have expired.
I gave up on trying to get a win32 app and switched to all x64. But I still cannot compile and run the DLL. The VB project and the FORTRAN DLL are both in the same solution and I know about "Native Debugging".
The problem that I get now is that the Linker says that I need an entry point for the DLL. This was never the case in Win32 and I don't understand why it is in X64.
I tried creating a Main sub in the DLL, and claim it in the "Entry Point" of the compiler options, but no luck. I tried to declare it with a Declare statement in VB as I do with all the other subs in the DLL. But the linker errors with "Error fatal error LNK1221: a subsystem can't be inferred and must be defined."
These are all errors that I have never seen before. No matter what "subsystem" I select I get errors.
Any help would be appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Show the command line for the link. Is /DLL missing? You would need /SUBSYSTEM:WINDOWS also. I would expect this is a settings error but I am guessing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It sounds to me as if your project is not a DLL project. Please attach a ZIP with the complete solution folder.
If you want a worked example, see the attached:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Attached is a vs2017 which I hope would be useful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your solution/projects work perfectly for me (all I did was change the destination of the post-build COPY command and rebuild.)
To be honest, I didn't expect it to work because the VB project targeted "Any CPU", and my experience was that this caused problems for native code DLLs, but it did work.
All I can suggest is to make sure that the COPY command is going to the right place.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve
I will Zip the project, but maybe not today as I will need to clean it up a bit.
One thing that I did notice is that the Link command line does not show a "/DLL" and under "General/Configuration Type" it shows "Dynamic-link Library", but it is all grayed out and can't be changed (which seems odd.)
I am also now getting an error: "Error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ) libcmt.lib(exe_winmain.obj) "
And none of that is my code. I don't know where this is coming from.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
libcmt.lib
is a standard Fortran/C/Windows library that you need.
If I had your errors and the code had worked on previous versions then I would first assume I did not install VS and the compilers correctly. This happens sometimes.
I would take a quick route - remove all of the VS and the compilers.
Update Windows and make sure you have the latest SDK
removing one of these can break your programs, trust me I learnt that the hard way
Reinstall everything and make sure you get all the batch files run for path etc.
At this stage I would start a whole new project and read the files one at a time to look for errors
of course this is drastic, but it faster than trying to fix project files and other corrupt stuff.
Good hunting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Other idea:
1. Buy an NIC i3
2. make sure it has a 500 GB drive
3. Join Windows Preview
4. Install VS 2019 Preview and then all your compilers
5. Get your program running -
6. keep the NUC upto date with all programs you have and that will tell you when things break, when they break on the NUC that problem will come to your main windows computer at some time later.
7. Enjoy the fun of running computers all over the world in multiple time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve
You example runs fine - once I changed it to X64. Same DLL error if not. I will look to see what the differences between out settings are.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, your code contains the "/DLL" in the link command line and mine does not. But I do not see how this can be resolved since the option is grayed in both our codes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1] Make a new project
2] add /dll is the extra options manually maybe.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think that when I get back to this (holidays and all) I will do just that. Start from scratch and rebuild the Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see I got confused as to who was asking the question!
If your link line doesn't include /DLL, then you do not have a DLL project. Easy way to tell is to open the .vfproj file in Notepad and look at the second line. It should be similar to:
<VisualStudioProject ProjectType="typeDynamicLibrary" ProjectCreator="Intel Fortran" Keyword="Dll" Version="11.0" ProjectIdGuid="{F0B8BF9C-D8BC-4B85-A93C-47A0AEBAED59}">
Note the ProjectType. If yours says something different, it isn't a DLL project. Recreate the project as the proper type.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve - thanks for the reply. But, the vfproj file does say exactly what your line says, so it should be a DLL. But the Linker does not have the "/DLL". I don't know how that is possible.
I think that what I need to do is to recreate the solution from scratch and see if that fixes things. I'll let you know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Me again
Created a new VB project and copied the files from the old project to the new. When I did that, the "main" form, which has all the controls on it, is blank. A user control that I created is also blank. How do I correct this without having to recreate the entire (complex) form?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That I don't know. I would think you could copy all the VB project files to the new solution.
Would you please ZIP the old solution and attach the zip to a reply here? I'd like to understand what went wrong.
![](/skins/images/C4F7392A5C68ACA60290C9576F107044/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page