Code coverage in 'Shared Item Projects' (VS2022)

[kx101]

Hi,

in our VisualGDB/VS2022 solution for a remote Linux system unit tests and code coverage works partially.
All source code in folders that belong to the VisualGDB Linux UnitTest project code coverage is fine.

However, all other source code, referenced via VS2022 ‘Shared Item Projects’ code coverage doesn’t highlight the
executed code. The unit tests are working correctly.
In source code files referenced through ‘Shared Item Projects’ no code coverage highlighting is visible although
that code must have been executed in the unit tests.

What can we do to get this going?

Thanks in advance for any help.
Nick

[support]

Hi,

The shared projects would normally just copy the list of source files into the actual project referencing them, using the rest of the settings from the main project. We have just rechecked it on a very basic project, and it worked as expected.

You can double-check what is going on by isolating a specific project and a specific source file that does not get coverage, and then:

1. Double-check that the project has the project-level instrumentation enabled (MSBuild Project Properties -> Instrumentation -> Generate Code Coverage Reports).
2. Double-check that the GCC arguments for the source file include the “-coverage” flag. You can check it in the .rsp files (local build) or .msbuild-ninja file (remote build).

Alternatively, if you can reproduce the problem on a minimal project involving 1 shared file, 1 non-shared file and no other overridden settings, feel free to attach it and we will investigate it further.

[kx101]

Thanks for your feedback.
After running unit tests code coverage is just fine in headers and gtest .cpp files but not in .cpp files located
in the shared items project.

Not sure if this is important but we do have issues with synchronizing files on the remote linux host (Ubuntu). We have to run
“rm -r <project-dir>” each time we changed code.
At this point it seems as if it doesn’t matter what Sync settings we have in “VisualGDB Settings”.
Could this contribute to the problem with the code coverage highlighting?

We continue to try to isolate both problems and try to provide a simple project that shows the issue.

• This reply was modified 1 year, 8 months ago by kx101.

[support]

No problem. We did recheck it with shared projects, so the issue could be caused by something else (e.g. symlinks in the target paths or some particular path syntax).

It could have the same underlying cause as the synchronization problems, but it’s hard to pinpoint anything specific from the observations you are describing.

That said, you can track down the second problem fairly fast as shown below:

1. Isolate a specific file that is not being re-uploaded. Confirm that just changing that one and building file doesn’t get it uploaded.
2. Create a new project with just one file from scratch. Confirm that re-uploading works with the brand new project.
3. Try gradually changing both new and old projects until they are equivalent (e.g. remove some files from the old one, add some files to the new one), rechecking the behavior after each step.

It typically takes less than 10 steps and almost always boils down to a 2-3 settings that were changed together in an unexpected way, and had an unintended side effect. You can also use diffing tools (e.g. KDiff3) to speed up the comparison.

Also, if you wish, we can do it for you via a screen sharing session at our consulting rate. It should take less than an hour to get it all sorted out (you only pay if it worked), however our consulting rate is fairly high and may not pay off depending on your constraints.

[kx101]

Thanks for the quick response. I guess we have some issues with the taget path setup.
Could you send a very simple solution with Item Shared Projects and how you set up the
targets?
Thank you in advance.

[support]

Sure, please see the attached file.

Attachments:

You must be logged in to view attached files.

[kx101]

thanks 🙂

[kx101]

I am still facing problems with synchronizing source code files from those shared projects. They are in a directory parallel to the VisualGDB test unit project. I tried several settings in “Synchronize Directories” etc. but code coverage still insists saying the source code file from that parallel directory is not mapped, which is not the case.

Is there a guideline on how to properly map local to remote directories in a larager project where the source code files in a parallel directory?
Somehow confused how to set it up properly.

Thanks for any help

[support]

Hi,

Both Synchronized Directories and pre-build steps should work fine.

If it doesn’t work, please make sure you can simplify the problem to a project that can be created from scratch and then provide the steps to reproduce it:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

As long as you provide the full repro steps, we should be able to point out the setting that is causing it, or provide you with a hotfix if necessary.

[Author]

Posts