Error: vgdbsettings does not exist

[george.r.wicks]

Hello:

I really like VisualGDB so far, but it does seem quite finicky. I used the tutorial https://visualgdb.com/tutorials/raspberry/ to create, build and run a test program. The tutorial was easy to follow, and it worked like a charm.

However, I decided to change the VS solution to have a new source file called src/RPiCauldron.cpp along with include/RPiCauldron.h, which I did via the VS Solution Explorer. However, I got the following error message:

“C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\SysprogsPlatform.targets(103,2): error : RPiCauldron-Debug.vgdbsettings does not exist. Please specify a valid VisualGDB Project Properties file for this configuration.”

Can you please tell  me what I did wrong, and how I can fix this?

It would be great if you could provide a more complete tutorial with how to setup a VS project with more conventional project structure that has src, include, lib, etc folders. Or at least, just pointers on how a developer could do that.

Thanks in advance.

G

 

 

 

[support]

Hi,

This error means that the project file is corrupt and may not work anymore. This type of errors is almost always caused by trying to do multiple new things at once and inadvertently selecting incompatible settings at some point (often while trying to troubleshoot an earlier error).

This is a very common mistake that can be easily avoided by trying new things one at a time and keeping notes of the settings you change, so you can always track them back. Please see this page for a very detailed description and our suggestions on best practices.

Our tutorials follow this approach as well – they demonstrate each individual feature (e.g. using libraries, using header discovery) separately from others, rather than trying to show them all at once and further confusing new users. We recommend using the search bar on the tutorials page to find relevant tutorials and following them as close as possible to get familiar with the related settings.

Please note that we do not update tutorials when introducing minor changes to GUI. If the GUI shown in the tutorial looks slightly different from the latest version, using the settings shown in the tutorial should still work, as long as you try to follow them as close as possible to the tutorial.

[jbusspx]

WoW, for a paid for product…that is some answer.

I had created a new configuration in POS Visual Studio and immediately got the above error. So I copied the existing configuration to the new name, and the problem went away.

I hope this helps others, because Sysprogs probably won’t.

[support]

No problem, we will try to explain our approach here.

The original poster did not mention adding a new configuration via VS Configuration Manager. They mentioned adding a source file via Solution Explorer, that does not lead to this error. So they must have done something else at the same time. They could have added a configuration just like you did, or they could have:

• Accidentally deleted the .vgdbsettings file (antivirus does this sometimes)
• Copied and renamed the project from a different location, but not updated the .vgdbsettings file
• Manually converted a non-VisualGDB configuration to a VisualGDB-based one
• Accidentally changed the .vgdbsettings file name in the configuration, intending to change it in another configuration
• Manually edited the .vcxproj file, trying to achieve something else

All these examples were taken from actual tickets submitted by other users. There are many other things that could have triggered the same error. In our experience, unless the user mentions exactly what they did, it’s practically impossible for us to guess it.

We initially tried suggesting the most common causes when users reported unreproduceable issues like this. It didn’t work out – the error was always somewhere else, the users would not have the patience to try every step we suggested, so they would submit more and more problems that we were powerless to solve. They were convinced that our product is buggy, getting increasingly more frustrated with every ticket; and we couldn’t do anything to help them because the steps they provided always worked just fine on our side, and the problem was triggered by steps they didn’t mention.

So we changed our approach – whenever someone reports an issue that we cannot reproduce, we ask to provide clear repro steps from scratch. As long as we can see what is going on, we can usually give meaningful advice. E.g. you mentioned using the VS configuration manager – indeed it will not update the VisualGDB files correctly. Instead you can use the Manage Configurations button in the top right corner of the VisualGDB Project Properties window – it will take care of both VS-level and VisualGDB-level settings automatically. But we really, really need to see what the user is actually doing to trigger the problem. Without it, the chance of suggesting anything remotely relevant is close to zero.

 

[george.r.wicks]

Hey jbusspx,

I gave up using vgdb a while ago. I got tired of all of the many quirks that happen during the development process with this tool. It came to a head when after I had gotten very far and then another weird quirk happened, and I was faced with a choice of starting back over from scratch again, OR abandon vgdb entirely and take a new route. I finally wised up and went on to Visual Code Studio. I’ve been with VSCode for more than 6 months, and I have much better progress.

One of the chief issues – and it IS a big issue even though the support person doesn’t want to admit it – is that many of the tutorials were written for older versions of the vgdb/sysprogs tools that have gone thru considerable changes that no longer correspond with the tutorials. I have mentioned that to him that they need to re-do the tutorials to match up with what the current toolset looks like, to which I got the reply that that was too much work. I completely sympathize that perhaps they are severely understaffed, but  that’s no comfort to me or other developers who have been getting headaches from all of the quirks, and getting told that the onus is on us dumb users. They are going to turn off a lot of users with that stance. They need to take a step back and try and look at it from the users’ perspective. I think it can become a very good product, but they need to realize that patience is a two way street.

Cheers,

G

 

[support]

Hi,

OK, we have reviewed our tutorials and indeed found a few confusing things. The most confusing part is that the older tutorials are showing the GNU Make build system and don’t show many features introduced later. We created a list of the most outdated tutorials and started updating them. So far, we have updated these tutorials:

• Developing firmware for EFM32 devices – showed the Advanced CMake workflow and the new Live Watch GUI.
• Using Visual Studio to develop Linux Apps – showed MSBuild instead of GNU Make and explained the differences between MSBuild and CMake.
• Developing a Raspberry Pi app with Visual Studio – showed MSBuild instead of GNU Make and the new Code Jumps GUI.
• Adding External Memories to Embedded projects – showed the new OpenOCD configuration GUI and the new Memory Explorer.
• Developing OpenOCD FLASH drivers for External Memories – showed the improved CMake workflow (instead of GNU Make) and the use of Software Tracing to record the issued QSPI commands.
• Using WiringPi library with Raspberry PI cross-compiler – showed MSBuild instead of GNU Make and gave examples on using automatic header file discovery and library discovery.

We will be updating more tutorials to show features like the new Software Tracing, and will also remove references to GNU Make that has been superseded by CMake.

As for VS Code, it follows somewhat different design principles. Instead of providing GUI for many repetitive tasks, it forces you to change many things manually by editing JSON files. On one hand, it is less productive because it involves more repetitive work. On the other hand, that extra work makes it harder to accidentally change the wrong setting.

VisualGDB is built around a different philosophy – it provides powerful tools for common tasks, but needs more attention when using them. A fairly characteristic example would be the Header Discovery that we showed in the updated wiringPi tutorial. Instead of manually finding the header file, manually computing the relative path, and manually finding and patching the correct CMakeLists.txt file, you can let VisualGDB find all these things for you, review them and commit everything with a few clicks. But if you end up referencing a wrong directory (e.g. for a different target) and then attempt fixing it by referencing several other wrong directories, it would break the project to the point where it’s impossible to tell what’s going on anymore.

We could theoretically try to reduce damage from changing incorrect settings on our side by maintaining a history of what was changed and having an undo button for settings, but it is harder that it seems. Some options (like the configurations/platforms mentioned earlier here) are controlled by the VS directly and hare hard to monitor on our side. Also, the majority of unrecoverable projects are caused by changing something very unexpected and unique (e.g. overwriting a toolchain definition while attempting to fix another issue for another project). The good news is that you can avoid most of such quirks by using source control (or at least, frequent backups) and taking notes when you change something globally (like overwriting global files).

Either way, if you decide to give VisualGDB another try, feel free to get back to us. We can extend your license by the amount of months you skipped. We still can’t promise to fix broken projects without having the repro steps, but we will assign a higher priority to updating the old tutorials and will make sure they match the current GUI.

[Author]

Posts