Closed quxflux closed 2 years ago
Sorry, just saw this... thanks for the great bug report!
From what I can see, your conclusions appear to be correct. Since you seem to be able to run GTA from source: Might it be an idea to add a "retry functionality" to the point where the DTE is received? I'm thinking about retrying for a couple of times (and e.g. once every second) in the hope that the DTE becomes available in time...
For what it's worth, a workaround might be to set the env variable as mentioned in the log output. This had been introduced because of a different (and now fixed) VS regression - the DTE is used to figure out the location of the solution settings file if I remember correctly, and by setting that variable you tell GTA where to find that file without reyling on the DTE object. I'm aware that this is not nice at all, but maybe better then having to live with the occasional problem.
Thank you for your reply.
I've implemented the suggested retry mechanism (actually more like a brute-force while
loop), which solves this particular error (so does the fallback file specified via the environment variable btw.).
Unfortunately my overall goal was to get the test adapter running with 3rd party dependencies not present in the test targets $(OutDir)
via placeholders in the PathExtension
setting, as proposed in #170.
There seem to be several places where the information which platform and configuration is selected does not get updated or populated in the first place properly. Two cases could be identified:
Debug
and Release
configuration (no update of the settings seems to get triggered), platformName
and configurationName
in the settings will keep the previously set value.GetVisualStudioConfiguration()
in GoogleTestExtensionOptionsPage
being called, which will not enter the if (dte.Solution.Projects.Count > 0)
branch and thus not populate the platformName
and configurationName
fields).As the PATH
variable does not get updated properly in these cases, loading the correct 3rd party dependencies fails and the test runners cannot be queried by the test adapter.
I gave up and will stick with the good ol' copy-all-the-dlls-to-the-output-directory method.
Ok, thank for letting me know... I don't think that I have any influence on when platformName
etc. are updated by VS - I just take what I get from the VS platform :-)
Closing this now - feel free to reopen...
Hello I'm trying to get GoogleTestAdapter running with a solution settings file containing a
<PathExtension>
setting. However, I'm not sure whether the contents of the settings file do matter for this bug. The used VS version is 2019 16.11.2. The Bug can be reproduced at least with GoogleTestAdapter version v0.18.0 and the current version inmaster
.Occasionally when opening a solution following log is written to the
Test
output:Because the solution settings file could not be loaded
<PathExtension>
will not be set, which in turn causes the test discovery to fail, since the test executable cannot find its required dependencies.When Debugging the extension, it can be observed that an assertion on
RunSettingsService.cs:126
is being triggered. This is caused byPackage.GetGlobalService(typeof(DTE)) as DTE;
resulting innull
which will cause the following statements to fail. Stacktrace:A solution which may be used to reproduce the error is attached. I'm a little bit lost here how to fix this. Does someone have an idea how to fix this issue?
google_test_adapter_bug.zip
Update The bug only seems to appear when the VS Test Explorer Pane is visible right at the startup of VS (which may cause the extension to be loaded to early before all dependent functionality is loaded)