- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bit the bullet. Installed the Fortran component of 2022.1 with VS 2022 (17.3x) integration. Opened my old solutions with .vfproj files from VS 2019. Build? Yup. Run? Yup. Same 32 and 64 bit results as before. Terrific!
But what about debugging? Ya know: Debug|Win32. (Or better yet Debug|x64.)
1. What happened to tooltip values?
2. What happened to querying values in the immediate window?
User error? Installation error? Some option I didn't see? I'm perfectly willing to accept responsibility.
Or... have we really regressed 10 years in usability and convenience within Visual Studio?
Thanks for any insight,
mike
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried the following steps to attempt reproducing the issues that you wrote about. I rarely use VS to build anything, and I use the VS debugger only when necessary, so I do not have any old VS projects to test the recently installed VS2022-17.3 and Ifort 2021.6.0.
I created an empty Fortran console project, and added an existing file to it. After building and starting an x64 debug session, I let the program run through seven statements in the main program, and then tested the tool-tip functionality and looked at the value of the variable f in the Immediate window. To test the expression evaluator, I asked for the value of 2*f in the Immediate window. Everything was as expected.
Do you mind trying to build and debug a new project from scratch, rather than a converted VS2019 project? If you get that to work, we can then think about whether something bad happened in the course of updating the project files when you opened a VS2019 project in VS2022.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That was a very comforting reply! Thanks. Did as advised and created a default debug|x64 wizard-generated console Hello, World app. Inserted a variable assignment and a break point.
! Body of Console1
x=4
print *, 'Hello World'
No tooltip appeared when I hovered. And the immediate window reported 'identifier "x" is undefined'.
One thought. I installed only the Fortran component as described here by Ron Green--not the full OneApi. Perhaps I need more components. That would be my next step--disk space is cheap!
Regards,
mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah: the answer is... installing the Fortran runtime "Intel® Fortran Compiler Runtime for Windows*" as well as the compiler and VS integration component. Although there is a strong implication that the runtimes are required only for distribution to end-user systems for executables that don't have the RT statically linked, here we are with the need for them to debug within VS. I love solutions like this!
While we're on it, have you seen the situation where .f90 files previously open in VS that you expect to reopen properly when the project is next loaded are not. You get
An error occurred in 'OnTrackCompMMX' while attempting to open 'NwkMain.f90'
This is VS 17.3.2, the only one I currently have installed.
And thanks again for leading down the right path.
mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Remember to install the OneAPI Base tool kit first, then install the OneAPI HPC tool kit.
If you still have problems with VS 2022 debugging, and you desire to use VS 2022 as an IDE,
as a hack (until issue resolved), place a PAUSE at the start of the program
Use Start Without Debugging (in VS2022)
Start VS 2019 (or your older VS that worked,
Attach to Process
attach to your running app
insert break points (if not remembered)
In app CMD window, press Enter.
While this is a bit awkward, it works.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This may be of help:
https://www.lifewire.com/how-to-fix-error-code-0x80004005-4689559
Error code 0x80004005 typically happens when you access shared folders or drives, use specific programs, or have a problem installing Windows updates. Here are the most common causes of error code 0x80004005:
- Problems with Windows Update.
- Moving or renaming files and folders.
- Windows notification issues.
- Problems opening or extracting compressed files and folders.
...
One of the other sites lists an issue with NuGet Package Manager.
Do you have a package manager installed (not necessarily NuGet)?
There may be a similar issue with other Package Managers.
Also see a YouTube video: https://developercommunity.visualstudio.com/t/an-error-occurred-in-solution-xyz-loading-while-at/954641
EDIT: The conclusion I get from watching that video is the cause may be due to a corrupted Project File (the poster's assumption is the corruption was caused by missing file on re-open of project). IMHO, it could also be caused by a share error from file on shared folder and/or AntiVirus (experiment by disabling the virus scan for your development folder(s)).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks to you both for your replies.
With the installation of the Fortran component of OneAPI HPC tool kit plus the Fortran runtimes (and the appropriate setting of Fortran Browsing/Navigation options--Text Editor, Fortran, Advanced), VS 2022 is now a viable Fortran edit/build/debug environment for me.
The sole sticking point is that any previously open file tabs produce the VSFM_MdiChild frame mode error when the solution is re-opened. Those files can be re-opened in the new session without error or incident. It's the equivalent of directing VS not to re-open documents on solution load--Options | Projects and Solutions. Annoying but tolerable.
This error occurs on my own projects plus on a newly created Fortran Hello, World console app, so it's not a corrupted .vfproj file. It doesn't occur in any of my c# or c++ solutions, and as they are the majority of my coding these days, I'll just live with it.
Who knows? The next point release of VS might change everything. Whew!
Thanks again,
mike

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page