I am facing an odd problem while using a mixed language (C++, FORTRAN) solution. While I am debugging the application's FORTRAN code/libraries, I occasionally stop the execution, change the source, recompile, and debug again. Very frequently, while I am trying to rebuild the solution IDE spit out the message "Error: The operation could not be completed" in the output tab one or more times. It seems one or more FORTRAN projects are failing to build. If I start building the project one by one, I can identify the projects which ones are failing. In most of such cases, no source code was updated in those failed projects. There is no additional message clarifying why the build failed; IDE is not even reporting the projects which have failed. It is just reporting "Error: The operation could not be completed". Unless I exit the IDE and restart the IDE with the solution, the problem continues. I have started encountering the issue after I upgraded the IDE platform to VS 2017 from VS 2015 and to Intel(R) Visual Fortran Compiler 184.108.40.206 from Intel(R) Visual Fortran Compiler 220.127.116.117.
What may cause this issue, and is there a resolution other than restarting the IDE?
I run into this problem occasionally when a program crashes, and then I correct the sources and try to rebuild and run.
Check if the EXE that you built is still running, using the Windows task manager or using the tool tasklist to do the checking. If so, terminate the EXE before attempting to build again.
That was a common problem. The problem (my prior problem) resided in MS VS leaving open the manifest file after a debug session. When the Fortran compiler goes to write the new manifest file, the build bombs out. The "fix" was to exit VS and re-launch VS.
A second issue may be related to an installed Anti-Virus program interfering with the build process (open file). You can test this by adding your build output folder to its exclusion list.
Has anyone actually been able to figure out what causes this?
I have run into this many times over a number of years now, and have seen no definitive answer.
I do not think it's a Fortran compiler issue.
I have the manifest off so it's not the manifest.
I cannot put the folder into an exclusion list for the anti-virus program due to corporate IT rules.
(I tend to think that this is the root cause, but I cannot prove it... if I could I'd go to IT and try to explain)
On the project I'm using now, it's only Fortran (no C++, nothing really even that complicated (except for the old F77 code).
Just two Fortran libraries, one Fortran exe with the 2 library dependencies)
Can anyone help solve this?
You need to look at the buildlog.htm to see what it was doing when the error occurred. Then you know what to focus on. The error message is too generic to be helpful.
Sometimes this error occurs after simply pressing the VS Start button to start program (console application) execution.
in other words, no library or executable files have been dirtied, and there was no need to rebuild.
That is why I suspect it's an external file I/O issue or an external (virus scanner?) which has a lock on something.
The project which fails seems arbitrary... sometimes it's library 1, sometimes library 3, sometimes the exe project.
I've looked at the build log and it's told me nothing.
The error always implies "out-of-date" on one of the projects (even if no files have been modified, as I stated earlier)
Just now I repeatedly pressed the Visual Studio Start button to start the program.
After repeatedly pressing it (thus running the program), eventually got the popup window with "This project is out of date"... Would you like to build it?
If you press No, the program will run as usual.
If you press Yes, you get the "Error the operation could not be completed" message in the output window, along with a window with the "There were build errors. Would you like to continue and run the last successful build?" message.
The Build Log reported no error(s) no warning(s).
And... no build was even necessary! I was simply pressing the Start button on a build that had been done hours ago with no modified files.
I have this problem with every new project I start. The solution is to delete the manifest file in the project properties. It's a real nuisance because I never remember to do this until after the problem occurs (i.e. the first time I try to run it).
I wish there was an option to make this setting the default for new projects, but I have inquired (on this forum) and it doesn't appear to be possible.
I don't know what this manifest file is good for anyway--it just causes trouble for me and lots of other users, judging by inquiries on this forum. I wish it would just go away.
It's primarily used to help Windows locate DLLs the program uses. Most people don't have problems with this. I suspect some antivirus software takes a dim view of a program modifying an executable.
I occasionally get this same error. Usually restarting Visual Studio fixes it, although I think I've had to restart the computer too.
Antivirus products have also been a problem. In my case, the latest trick is deleting my executables right after I start running a recent build. The fix involved getting added to the AD group that allowed digital signing, obtaining a digital certificate, and adding a post build step that used the signing tool to sign my executable. And finally I had to get my certificate added to the anti virus whitelistl.
Another antivirus trick that I ran into was a program that would fail, but only when I wasn't watching. Worked out that the failure occurred right after the screen saver kicked off. The behavior that triggered all this was an error log file that was being opened at the beginning of a calculation loop, and then closed at the end. Since there were no errors to log, the file was created with 0 length. The program would do this many times during a run that lasted several hours. I'd run off to a staff meeting and come back, to find that the program failed trying to open the log file, because something else was using it.
I can understand why the antivirus software would find 0 length files to be suspicious, since this sets aside a cluster on the disk where bad things can be hidden. But apparently scanning the file wasn't a high priority, and was only done when the computer wasn't busy interacting with the user. When the screen saver kicked off, the antivirus software kicked things up a notch, and started scanning the 0 length file, which created the file contention that crashed the program. Cute.
Nice detective work.
>>and adding a post build step that used the signing tool to sign my executable
If your development folder is not a scan exclusion folder then you have a race condition with the AV between the time the .exe file is closed and when your signature is posted into the whitelist (assuming the whitelist isn't buffered in the AV, which could result in longer exposure time).
Actually not. After I got the digital certificate, and created an executable (without trying to run it), I had to contact the fellow in charge of our antivirus, who remoted into my machine, and did some magical thing that extracted the certificate from the executable. This was a one-time thing. After adding me to the whitelist, all executables created using this certificate are unmolested by the antivirus software. My understanding is that the certificate will expire at some point and I'll have to get a new one, and go through that part again. But I used a timestamp option in the signing tool which will allow executables created with the old certificate to still work after the certificate expires:
"c:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" sign /t http://timestamp.digicert.com /a MYEXECUTABLE.exe
Note that this signing is different from the signing built into Visual studio, which I think applies the signature to the manifest. I have the impression that one doesn't normally sign executables anymore, but it's the only way I can debug my code.
>>but it's the only way I can debug my code.
I suppose you cannot get your system administrator to add your development folder to the exclusion list.
Not sure why they won't do it with the exclusion list, but this is what they told me I had to do. Works out better this way anyhow, since at least one of the programs I am working on has to be tested on a signficant number of machines at numerous locations to test a bunch of different data acquisition methods.