Tagged: VisualGDB properties
March 22, 2019 at 10:34 #24422
I have just updated my Custom VisualGDB installation to the latest 5.4R3 (build 3000) but have started to see a few problems. The biggest problem is losing the VisualGDB properties configuration page:
This is a big problem now for a few new projects I have just created.
How can I get this option back?March 22, 2019 at 11:51 #24427
I’ve noticed the same issue.
I think the issues come with the decision to not start VisualGDB when Visual Studio starts but rather “when it’s needed”. The problem is I don’t think it works when you start Visual Studio and at the same time opening a solution with VisualGDB projects, IE starting it by opening a .sln file etc. Then it doesn’t seem to recognise that it should actually start VisualGDB.
My current solution is to just open the “HELP -> About VisualGDB” window. That will load VisualGDB and the properties appear.March 22, 2019 at 11:57 #24428
Thanks for help. Opening the HELP window didn’t work for me but following on from your thoughts about the cause I closed the solution (not VS) and reopened it and the properties page is back. I’ll probably play around with other combinations to find the easiest. At least I know I can (hopefully) always get the option back.March 22, 2019 at 11:57 #24429
Same issue here. As a workaround you can rightclick your project in the solution explorer and there should be the VisualGDB project properties window.March 22, 2019 at 17:41 #24432
Sorry about that. We have already fixed it in this build [VisualGDB-188.8.131.5220.msi] and will release R4 including the fix in the next few days.April 10, 2019 at 11:45 #24634
I still have the same issue with the R4 release (build 3031).
Opening a solution with visualgdb projects in it it actually works to build it but there are no visual “VisaulGDB Project Properties” available when right-clicking a project. Also debugging doesn’t work.
To fix it I still have to open the Help menu and open the “About VisualGDB” dialog. Then it takes a couple of seconds for it to load VisualGDB and then everything works again as expected.
Not sure if it’s different in any way but the way I open it is I have Visual Studio pinned to the taskbar and right click on it there and use the recent/pinned solutions to open it.April 10, 2019 at 18:48 #24642
Sorry, we were not able to reproduce the problem based on your description. If you could reproduce the problem on a newly created LEDBlink project and share it with us, we should be able to reproduce it on our side and fix it.April 12, 2019 at 08:43 #24657
I tried to reproduce it with a fresh empty project but it seemed to work fine there. Perhaps there is something wrong with our project files that causes it to behave like this?
We still have the “Convert Project to MSBuild” option on them just below the “VisualGDB Project Properties” one. Clicking it just opens a window saying there are no configurations that can be converted though. That option isn’t there either on the new test project I created to test it. It was years ago however that we did that conversion though so I don’t remember that much about it except that it wasn’t as easy as just clicking the menu 🙂
Before testing for this I used the default VisualGDB platform target though and now while testing I created a new platform target for the test project and used the same as we have in our real projects and then the “Convert Project to MSBuild” menu showed up for the test project as well. It still worked and shows up the “VisualGDB Project Properties” directly from start on it though.
Our projects are a bit complicated since many of them contains platform targets for multiple linux systems and windows as well. Getting that to work has required a lot of manual editing of them to get the right references for the right projects. As in, one “high” level project could be identical for all platforms but reference 3 different “low” level projects for the HW implementation. We couldn’t get the references to work well using the Visual Studio GUI in this case (It doesn’t work well for Visual C++ either so don’t feel bad :)) so we edited the project files manually to get them to reference different projects based on their platform configuration.April 12, 2019 at 17:53 #24658
Thanks for the description. Looks like some of the changes you made to the project are indeed preventing VisualGDB from being loaded. The latest VisualGDB 5.4 uses a 2-stage mechanism to load itself. First, it starts a very lightweight project loader that checks the opened .vcxproj files for the $(VISUALGDB_DIR) or <Platform>VisualGDB</Platform> text. If not, it assumes the project is not VisualGDB-based and skips loading the rest of VisualGDB. This eliminates any delays when loading non-VisualGDB projects (fully initializing all VisualGDB components does take a few seconds).
VisualGDB projects created via the wizard should contain one of those strings, however if you have manually removed them, indeed the 1-st stage loader will consider this project to be a non-VisualGDB one and will not load the main part of the plugin. Please double-check the .vcxproj file for the strings mentioned above. If they are not present, please try comparing the file to a newly created .vcxproj file and adjust it accordingly.
Let us know if you need further details and we will be happy to help.April 15, 2019 at 08:34 #24671
Ah, that must be the issue. For our projects we’ve followed the guide you have to have multiple VisualGDB platform targets with different names: https://visualgdb.com/tutorials/porting/multiplatform/
Then we’ve removed the default VisualGDB platform so we don’t get confused by it and only use the ones aptly named for the targets 🙂
So our solutions doesn’t actually have any platform called VisualGDB which it can find. Perhaps you should follow toolchain name and check in the folder that’s copied in the tutorial to see if other names are VisualGDB projects as well?
The other option the environment variable $(VISUALGDB_DIR) I do have that one when the projects are running but it’s not mentioned anywhere in the project files. Neither the completely new ones or our old ones.April 15, 2019 at 17:11 #24674
Thanks for clarifying this, it indeed looks like we missed this scenario.
The logic for quickly checking whether a certain project is a VisualGDB-based one is designed to run as quickly as possible without loading any advanced objects, so it isn’t able to do any advanced checks like following the toolchain names. However, we can check for other markers (e.g. references to .vgdbsettings files) that would be present in the file.
Would you be able to send us your .vcxproj file so that we could check for the best way to update our first-stage loader?
You must be logged in to reply to this topic.