Hello all, brand new on the forum, please bear with me.
I have recently migrated all of my Parallel Studio XE Fortran projects from the 2017 (17.0.1675.2) version to the 2020 initial release (19.1.1555.0) version. I have also (by necessity since 19.0 Update 2) migrated from the MS Visual Studio 2013 Shell to the full Visual Studio 2017 Community version.
The Intel Fortran interface successfully installs in VS 2017, and existing projects will open correctly. The problem I'm having is that when I try to re-build an existing DLL project from scratch in the new VS environment, I get a linker error:
"MSVCRTD.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)"
From a cursory investigation online, I'm gathering that this error indicates that VS doesn't seem to realize that this is a DLL, and it's looking for an entry point (i.e., a Program statement) somewhere in the source code. However, the project was explicitly identified as a Fortran DLL when it was created, and indeed, the Configuration Properties page shows the Configuration Type as Dynamic-Link Library, and the Target Extension as .dll.
I then opened the projects simultaneously in VS 2013 Shell and VS 2017 Community, and laboriously marched through all of the configuration settings to make sure they matched, which they did, except for one inexplicable difference: in the VS 2013 Shell, the Linker Command Line shows the /DLL option set, whereas in VS 2017, this option is missing! Moreover, when I manually add the /DLL option to the VS 2017 command line (via the Additional Options box), the DLL compiles and builds just fine!
My understanding was that a Configuration Type of Dynamic-Link Library would automatically invoke the /DLL option in the VS Linker command line... it certainly did so in the VS 2013 Shell. Any ideas as to why this manual intervention is necessary, and/or how to get set up so that it isn't necessary?
Thanks for any info!
Interesting. Your two x64 configurations were missing 'LinkDLL="true"' in the VFLinkerTool lines. I don't know if there's a way to change this in Visual Studio - it should have been propagated automatically when you created the x64 configurations. When I try this with a new project, it works as it should.
I hand-edited the ,vfproj to fix this - try this one.
When I open your hand-edited .vfproj file in VS2017, it properly shows the /DLL option invoked in the linker command line, and the DLL compiles and builds with no problems, just as it does when I manually enter /DLL via the Additional Options box.
I compared your hand-edited version of the .vfproj file with the corresponding one created using the VS2013 Shell, and the latter already contained the LinkDLL="true" statements in exactly the places you had inserted them manually!
So, of the two potential workarounds here, i.e., (1) manually edit the .vfproj file, or, (2) add "/DLL" in the Additional Options box, I guess I'm leaning towards the latter, with still no clue as to why either should be necessary.
I'm starting to think this issue may be more on the Visual Studio side than the Intel Fortran side, but I'm loathe to wade into the VS forum, where I'd be even more hopelessly naive than here.
I should note that I did perform a custom install of VS2017, which was pretty bare bones... I did retain all of the modules required for Intel Fortran integration, but I can't rule out that I left something out that I shouldn't have. I can provide the VS2017 install command I used if that might lend any clues. Thanks for your assistance-
I don't think that it was a missing component, but to be honest I have no idea how this happened as I have never heard of it before. You should not have to manually edit the .vfproj.