Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Intel Fortran Integration with Visual Studio Issues

Timothy_W_
Beginner
1,454 Views

Hi

I am running Visual Studio 2015 and Intel Parallel Studio XE 2016 Composer Edition.

Coming from C++ development to Fortran, I find the integration with Visual Studio incomplete and buggy.  I am creating a solution with over 70 projects, mostly Fortran some C++.

Issues I see are:

No support for property files *.props in vfproj files.  Since I have a lot of fortran projects, I can't use property files to define common paths etc like I can in C++.  I have a lot of duplication in the vfproj files. If I change something in all of them, it is a big pain and error prone.

No support for querying existing macros when editing vfproj files in Visual Studio.

vfproj -> Configuration Properties -> Linker -> Input -> Additional Dependencies does not handle separating the files by semicolon like C++ projects.  The resulting command line contains a.lib;b.lib;c.lib;  The C++ linker resolves the same list to the command line as "a.lib" "b.lib" "c.lib".  When I run the Fortran linker project, it complains that it can't find file 'a.lib;b.lib;c.lib'.

Visual Studio 2015 gets stuck and won't save project information.  After Visual Studio has been open for a while, maybe an hour or so of updating and saving project files, it stops saving.  I can click on save all but the files are not saved.  If I quit visual studio, it tells me that some projects have not been saved would I like to save them.  I say yes, and it does not save them.  Until I knew to be careful, I lost about a day's work.  I am assuming that this issue is because of the Fortran integration.  The Fortran projects are affected.  I have many years experience with Visual Studio and I have not seen this problem before.  It could be Visual Studio 2015 since it is new.

The build step is slow and locks Visual Studio.  So if I tell it to build the solution, visual studio becomes unresponsive as it thinks.  So I have no ability to cancel the build.  At least I have not been able to do this.   VS does eventually start building but it is still hard to cancel a build once it starts. 

I can't in Fortran project properties switch between a static lib or a DLL.  I can in a C++ project.

Some of this might be because the vfproj files are not msbuild.  Microsoft does recommend to use msbuild and their system is moving toward it.  Is there plans to switch vfproj files to msbuild?  

What I want is a way I can reliably build this big project so I can build at will in a continuous integration server.  I am still working on the build system which has many problems besides the above list.  So at this time, I don't know if calling devenv on the solution will work.  I hope so.

Does anyone else have a continuous integration server that automatically builds a big Fortran/C++ project?  Were they able to use Visual Studio solution and project files?

Thanks

Tim

 

 

 

0 Kudos
14 Replies
Steven_L_Intel1
Employee
1,454 Views

As you note, Fortran is not using MSBUILD yet. We do have plans to make this transition, perhaps for the next major release.

However, I haven't seen other reports of the slow build and unresponsiveness issues you report. As I noted in your other thread, a test case you can send us would be very helpful in resolving these issues.

0 Kudos
Timothy_W_
Beginner
1,454 Views

If it helps set priorities, adding msbuild would get my vote.

I am not sure if I will find the time to generate a solution file with projects that exhibit the problems I have described above and in other posts. Since I am not using IPO, I can convert all my fortran dll projects to c++ dll projects since they are only dependent on the obj files not source.  This seems to be solving many of my problems.

Thanks

Tim

0 Kudos
Steven_L_Intel1
Employee
1,454 Views

We know we need to move to MSBUILD, especially as Microsoft is removing support for the interface we use. But it won't come before the next major release (calendar year 2017).

0 Kudos
Deniz_S_
Beginner
1,454 Views

May I invoke this thread to concur with the OP with the getting stuck/not saving issue.

I am running Visual Studio 2015 (update 3) and Intel Parallel Studio XE 2017 Composer Edition.

I have worked with various versions of the combination for years without issues, but only recently upgraded from VS2010 to VS2015.

Thanks,

Deniz

0 Kudos
Timothy_W_
Beginner
1,454 Views

Deniz

Thanks for your post, it is reassuring that others see the same problem!

Do you get "Error: the operation could not be completed" message?

When I debug my executable, it takes a while to determine if it needs to rebuild.  This could take a while.  Then it would give me a list of projects that need to be rebuild.  Many of them I know don't need rebuilding.  This could be a configuration issue on my part.  When I tell it to rebuild, it might fail on some of the Fortran projects.  I get the "Error. The operation could not be completed" for each project.  Each time it sees those Fortran projects as failing.  I know they did not fail and that last successful build is good.

This is very irritating and time consuming.  I did find one post which recommends reinstalling Intel Fortran which I might try.

I really wish (give my third born son!) that Intel would switch to Msbuild instead of devenv.  I hope that would solve some problems plus allow Fortran compiler settings to use solution wide user defined properties.

I hope to create a dummy solution with many fake Fortran projects and files to see if I could recreate this problem.  Then I will send this to Intel to debug.

Tim

 

 

0 Kudos
Deniz_S_
Beginner
1,454 Views

Tim,

I occasionally get the "Error: the operation could not be completed" message, even when the build is complete.

My main issue is as you have described: I would make changes to a file, but save/save all/ctrl+s does nothing. I have to copy the whole file, close VS (save solution is offered, but does not work), then reopen and paste. It always works after reopening. Occurence is haphazard, may be every few hours, very annoying!

Another issue is with regard to updating of debug database. Most often it would not update within a standard build, I have to clean/rebuild the whole project.

Cheers,

Deniz

0 Kudos
Craig_T_
Beginner
1,454 Views

My organization frequently builds a large program consisting of about 60 Fortran projects and a few Microsoft Visual C++ projects, similar to what Tim reported.

We previously used Visual Studio 2010 (and VC 2010) and ifort 14. It was unstable and prone to "Error: the operation could not be completed" error messages which opaquely meant that one or more (unnamed) static libraries were not actually built. However, using VS2010 we've always found that after restarting Visual Studio 2010 when this happens will cause the very first subsequent build attempt to not feature the "Error: the operation could not be completed" severe annoyance, providing a workflow workaround. We've tried many combinations of reinstallations of both Visual Studio 2010 and ifort 14 (with or without newer integration packages from ifort 15) to get rid of this without success. One of my colleagues reported some improvement after removing the .suo file (and then painstakingly re-defining breakpoints and other configuration info), but over time the problem would strike again.

More recently we've been evaluating Visual Studio 2015 and newer ifort compilers. We've tested Visual Studio 2015 u2 and u3 and ifort 2017 and recently ifort 2018.0.124 with integration v18.0.0033.14. For our latest Visual Studio 2015 u3 and ifort 2018.0.124 test we were very sure to run on a machine without prior installation of either Visual Studio or ifort to rule out possible uninstallation problems we've encountered before with the toolchain. These tests were using Windows 7 SP1 x64 with Windows SDK 10.0.16299.15 installed.

We unfortunately have encountered in this testing the same very severe data integrity bug (somewhere in the toolchain) reported by Tim and Deniz. I'll add that we see the asterisk indicating the file is not saved {correctly}, but there's nothing we can do to save the file from VS2015 anymore when we get in this ill-state. Since the natural approach when this happens is to close Visual Studio, the bug feature that VS2015 then does prompts us if we want to save the file following a close Visual Studio event but it does NOT save the file user selects to save the file is a major showstopper problem for us.

This could be random, but one thing my colleagues and I who have seen this have noticed is that this only seems to happen after working in the same Visual Studio session for many hours. We've encountered it probably a few dozen times collectively, and I believe every time it happened it happened late in the day. Again, this occurrence might be related to some random timing issue, but in case the comment elucidates some periodic operation that may be to blame I thought I'd comment.

In addition to the saving problem that [while horrible and fraught with the potential to lose many hours of valuable work] does at least have visible indicator (i.e., the sticky asterisk in the VS file tab), I've additionally separately encountered an "invisible" toolchain bug whereby newly changed files are not detected as in need for rebuilding. Unlike the other two problems this problem is sticky and persists in one of my fortran projects to date - after full system reboot. Manual builds of individual files and manual links of the project still work, but building logic always thinks everything is up-to-date. This is extremely disruptive as it becomes unclear in subsequent debugging that changes were not adopted in the final .exe build. My colleague opened an Intel ticket for this detection failure.

Deniz and Tim, thanks for your posts. One aspect to our workflow is that we use the P4VS plugin from Perforce. While all of the above problems persist even after P4VS has been disabled, I was wondering if either of you were using any Perforce plugins at any time during your tests. My colleagues and I do have this plugin installed and it was enabled at the time the toolchain first went off the rails. Can you also comment on your OS and if Windows SDK version if applicable? Maybe if we uncover a pattern Intel will have more success resuscitating a workable Windows Fortran toolchain.

0 Kudos
rwg
Beginner
1,454 Views

Same problem here!

My Solution contains about 60 Fortran projects (static libraries) and some c++ projects (dlls and static libraries). Recently I added some c# projects.

We had the problem that changed files were not saved. But after removing the .suo file this problem was gone.

Currently we still fight with the message  "Error: the operation could not be completed​". When I get this message I press F5 again to see which projects will be rebuild (which is obviously unnecessary) and unload and reload those projects. Pressing F5 again results in correct linking without any compilation in the reloaded projects. But this does not always work. If reloading does not help I have to restart Visual Studio.

Currently we are working with Visual Studio 2015 and Intel Fortran 2017 Update 4. I wanted to try Intel Fortran 2018 Update 1 but got some installation problems. Has anyone seen the message "Error: the operation could not be completed​" with IF 2018 Update 1?

 

 

 

0 Kudos
Timothy_W_
Beginner
1,454 Views

Hi rwg

I am now using the latest Visual Studio 2017 and Intel Fortran 2018 update 1. With my visual studio solution of 87 projects, 28 of them are Fortran.  In Fortran 2018 update 1, Intel fixed a dependency analysis problem where Visual Studio would just lock up for minutes, maybe even 10 minutes before it decides to start building. Now it starts building quickly and does seem to do a good job determining what to rebuild. (I am still investigating that).  

I think there has been some improvements in Visual Studio too which makes it work better and quicker.

But I still get the "Error: the operation could not be completed​" problem occasionally.  Now it is quick enough to just restart Visual Studio and the problem goes away for a while. ( I haven't tried the F5 trick you mentioned). I might try to create a dummy visual studio solution with many Fortran projects and see if I can get it to happen consistently and send that to Intel to fix it.

My other complaint about the Visual Studio integration is that the Fortran project files are not msbuild.  They are the old devenv? style projects. This means that they can't be used with any Continuous Integration msbuild tool.  It also does not allow for creating separate property files that can be shared between projects. So if a setting must be changed on the Fortran project, it must be changed by hand in every project. This is tedious and error prone.

I used to have the problem that the files or project configuration was not saved and would not save. I had to restart visual studio and reenter my project changes and save. But with Visual Studio 2017 and Intel Fortran 2018 update 1 I have not seen this problem. I did not know about the deleting .suo files trick.  Good to know.

Tim

0 Kudos
Timothy_W_
Beginner
1,454 Views

I should mention that Intel has informed me that providing msbuild support is on their to do list. They haven't told me when it would be done.

Tim

0 Kudos
Craig_T_
Beginner
1,454 Views

Some updates that may be useful:
1) Using the same hardware and same versions of VS & ifort, I've observed the "Operation Could Not be Completed" to be greatly mitigated after upgrading to Windows 10 OS (instead of Win 7 with with Windows SDK 10.0.16299.15). However, the problem was not entirely removed, it just reduced in frequency of occurrence {from several times per day to a few times per month}. Some of my colleagues still using VS2010/ifort14 also experienced noteworthy reductions in the problem by updating from Win7 to Win10 in a similar fashion.

2) After updating to Windows 10 the toolchain problem I reported in quote 8 (otherwise unique in this thread so far) where updated source code wasn't appropriately built has yet to resurface.

3) After updating to Windows 10 and using VS2017 & ifort2017u6 (we found ifort2018 to be relatively slow in performance compared to ifort2017), the data integrity error ("sticky asterisk" thing) has still been encountered numerous times (albeit infrequently).

4) *new* linking static C libraries included in a VS2017 .sln to a Fortran application works most of the time, but occasionally the linker's path to the static library gets messed up. This lack of reliability is very problematic for auto-build systems, so we're taking pains explicitly point to C/C++ static libraries and pre-building them.

It seems like msbuild has been on Intel's to-do for quite a long time already. Has Intel ever explicitly explained which reported sporadic stability problems they think will be resolved by moving to MSbuild?

0 Kudos
Haustein__Christoph
1,454 Views

Hi,

after my company updated my computer to Win10, I fail to install my old VS2010/ifort14 package. Is there a way of using the old installation any longer, or do I have to upgrade. I tried to integrate ifort14 to VS2017 professional, but these two don't seem to recognize each other.

Maybe sombody in this forum can help me.

Thanks,

Christoph

0 Kudos
Craig_T_
Beginner
1,454 Views

Timothy W. and Deniz S.: Regarding the particular point about new Visual Studio (2017 & 2015) not saving files reliably, my colleagues and I have uncovered reason to suspect that this is a Microsoft Visual Studio bug unrelated to the Intel compiler or its integration package (or lack of MSBUILD). Microsoft forums such as this one:

https://developercommunity.visualstudio.com/content/problem/165245/save-not-doing-anything.html?childToView=231713#comment-231713

are indicating this problem is being seen by Visual Studio developers not using an Intel compiler.

Quite recently, one of my resourceful colleagues discovered that while the save operation from the Visual Studio UI apparently appears to be prone to being blocked (by presumably competing runaway threads?) in Visual Studio 2017, if he invoked the save operation using a custom .vsix add-in he wrote the problem is somehow effectively bypassed. Several of my colleagues have now reported seeing the dreaded "sticky-asterisk" problem arise, and were subsequently able to save with minimal disruption by using his add-in save mechanism instead. He'll be adding a comment to the above Microsoft forum link soon if you want more information if you're inclined to create your own similar workaround.

--

Hi Christoph. You can't integrate ifort14 with VS2017 (or VS2015) to my knowledge (Intel documentation states as such).

The Windows OS (or something about .NET framework with each OS) did play a role in toolchain stability, however. I evaluated a number of VS and ifort combinations a few months ago. It was important that our developers would be able to continue to use ifort14 with VS2010. We could not use VS2010 for newer ifort, so we evaluated having both VS2010 and newer VS2017 both installed on the same machine as a solution. I found that when this is done installing the newer ifort compiler gives a warning message that sounds like it'll destroy the ifort14/VS2010 integration, but it appears this does not happen (though it will happen with newer ifort).

For what it's worth we ultimately landed on VS2010/ifort14 & VS2017/ifort17u6 compiler with ifort18u1 integration package working for us only if Windows 10 OS is used (not just Windows 7 with SDK).

0 Kudos
Steve_Lionel
Honored Contributor III
1,454 Views

Christoph, you should be able to install it if you still have the license file. If not, but you have the serial number, submit a ticket at https://supporttickets.intel.com/?lang=en-US and ask for assistance.

What error do you get?

0 Kudos
Reply