Exception on opening "VisualGDB project properties"

[Jensa]

Hi,

I was doing a bit of rework on our projects/solutions and was trying to change so we only have one solution and one project for each application/library. Before we’ve had a bit of a mix of projects where some had multiple project files for different target platforms etc and some have had all targets in one project etc.

I was following the https://visualgdb.com/tutorials/porting/multiplatform/ as a base to add the different targets to existing projects but I ran into an issue. After step 18 where I’ve added everything seemingly correctly and working I tried to open the “VisualGDB project properties” again but then I got an exception. See attached picture and stacktrace.

Now I can’t open it at all, even with my old unchanged projects I get the same exception. I tried repairing my VisualGDB installation but it didn’t help either.
The file referenced in the stacktrace that’s missing (user-root.png) isn’t any file I have at all anywhere in my computer so it’s no wonder it can’t find it.
Any ideas what’s wrong?

• This topic was modified 2 years, 7 months ago by Jensa.

Attachments:

You must be logged in to view attached files.

[Jensa]

I got it working again, installed an older version (VisualGDB-5.6.105.4579) and then it worked again.
Tried to update to the latest one I got from you for another reason (VisualGDB-5.6.105.4583) and it doesn’t work again so it seems something is wrong with that version.

[support]

Hi,

Sorry about that. We were doing some resource-related refactoring in our development branch, and it resulted in a few broken references in the daily VisualGDB builds. We have fixed it in the latest build: VisualGDB-5.6.105.4588.msi

[Jensa]

Hi,

No problem. The new build seems to work fine.

Also it seems to work great with the test explorer running the bigger test projects that we have too, even with gdb. Though our biggest test project is something around 60k characters so I guess it was above a ssh limit but not the shell limit. Perhaps the issues you’ve seen where it doesn’t work was around the shell limit?
Either way it seems to work great for us now and it will be a long time before we’ll ever reach that 131k shell limit (if ever).

The only issues left that I’ve seen has to do with the test discovery. Now for instance one of the projects test didn’t get listed under the real project name but under the name “External”. All tests seem to be there and it worked perfectly to run them all though so it’s not a big issue.
I’ve also seen cases where it didn’t group them under the test fixture classes but had all tests directly under the project name. Also some cases where the “value parameters” got missing and it only showed the test fixture and one test each without the value parameter. We use the “Value-Parameterized Tests” a lot in our tests.
But I haven’t looked into those thouroughly since we had bigger issues with the tests not running before. Also so far I haven’t seen anything other than the “External” happen with the last build so it’s not a big issue.

Regards
Jens Nilsson

Attachments:

You must be logged in to view attached files.

[support]

Good to know it works.

There was indeed a bug preventing VisualGDB from turning on the SSH command line limit mitigation, and we fixed it in this release. Also the 131K shell limit should no longer be a problem with GoogleTest, as the long GoogleTest command are now passed via a command file that is directly read by the GoogleTest framework, completely bypassing the shell (similar to GCC response files).

Regarding the test discovery, it looks like it’s caused by some combination of VS test display rules and your project configuration. Please try reducing the problem to something that can be reproduced from scratch (i.e. a solution with 2 freshly created projects). Once you can point to specific settings triggering it, we should be able to suggest a workaround or release a hotfix.

[Jensa]

I haven’t really seen any issues with the test explorer or running tests with the new VisualGDB build. Also I’ve pretty much recreated all our projects to be able to cosolidate them into one project for all targets instead of having them separated by the target as we had before.

One thing I did notice now was that we have a couple of projects that are target specific only and not set to build for other platforms. But it seems that the unchecked “Build” box is ignored when it comes to test explorer and it’s features. Normally that wouldn’t be a big issue but since in this case its remote targets VisualGDB tries to connect to them to deploy the tests which in this case doesn’t work well since they may not all be connected when you’re currently targeting another platform.

I’m not sure if it’s an issue with VisualGDB itself or if it’s just how Visual Studio handles the test explorer internally. I tried disabling a Win32 project as well and it still showed up in the test explorer so it might be just a Visual Studio issue. But since it gets much more annoying when it’s a VisualGDB remote linux application I thought I would mention it here as well.

[support]

Hi,

Just to double-check: you are observing that unchecking the “build” checkbox in Configuration Manager for a particular project moves the unit tests from it into the “external” category, rather than hiding them as expected, correct?

[Jensa]

No, what I observed was that the test was still in the explorer like normally and VisualGDB tried to deploy it to the target (that in this case wasn’t connected) to identify it’s tests.
A clean didn’t help since it was unchecked in the build configuration so it didn’t clean it. Only manually deleting the output worked to avoid having it deoployed etc.
But I tested the same thing with a Win32 project as well and it was the exact same behavior there so It’s probably more of a VisualStudio issue in essence. Only a bit more annoying when its a remote target that’s deployed.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the clarification. We have managed to reproduce the behavior – indeed VisualGDB was ignoring the “build” flag in Solution Explorer when enumerating test projects.

We have fixed it in the following build: VisualGDB-5.6.105.4604.msi. Please note that if you change the build flags while the solution is open, you would need to reopen it or close and reopen the Test Explorer window in order for the changes to take effect.

[Jensa]

Hi,

Got the time to work on some unit tests today again and it seems to work a lot better than before. It hasn’t tried to deploy anything except to the target I was actually targeting now.

Thanks!

[Author]

Posts