Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS2017 ERROR: couldn't find the msdia.dll #124

Closed
Farwaykorse opened this issue Mar 30, 2017 · 13 comments
Closed

VS2017 ERROR: couldn't find the msdia.dll #124

Farwaykorse opened this issue Mar 30, 2017 · 13 comments
Assignees
Labels
Milestone

Comments

@Farwaykorse
Copy link

Test discovery returns:

ERROR: Couldn't find the msdia.dll to parse *.pdb files. You will not get any source locations for your tests.
Warning: Could not find source location for test testclass.testname

For each pdb and all tests in them.

On this pc only VS2017 is installed.
My first idea is that the new directory structure might prevent the runner from finding these files.

The test themselves work properly, and return the proper messages. Just without the source links.

Google Test Adapter v0.9.1.653
VS Community 2017 / 15.0.0.0+26228.1
.NET v4.6.01586

@csoltenborn
Copy link
Owner

Thanks for your detailed bug report! However, we are not relying on file locations (see this line), so something else must go wrong...

Can you please verify that your VS installation indeed contains the DIA stuff? Search for msdia within the VS20127 folder...

@Farwaykorse
Copy link
Author

It seems the files are there.
https://gist.github.com/Farwaykorse/27e4d854e12b74ecf79a8f198c0929f0

For now I've tried repairing the installation and a second install using 2017 preview with a basic c++ workload.

@csoltenborn
Copy link
Owner

Thanks! Could you please also search for e6756135-1e65-4d17-8576-610761398c3c (and maybe also
3bfcea48-620f-4b6b-81f7-b9af75454c7d) within your registry? Just in case: Use the regedit tool for this... If you do have findings: Are they located within a CLSID folder?

Explanation: We are using CLSIDs to instantiate the DIA COM objects - they should be made available through the registry. If you do not have any findings, the VS2017 installation has not added them to the registry for some reason. In that case, we will have to investigate the VS2017-only case a bit closer.

@csoltenborn
Copy link
Owner

@NinjaCoder Thanks for adding that information! You say that it started on March 14th - does that mean that source locations worked before that date on VS2017 even without having VS2015 installed?

@Farwaykorse Can you confirm the problems with debugging tests?

@csoltenborn csoltenborn added the bug label Apr 3, 2017
@Farwaykorse
Copy link
Author

I do have both keys. Both are located in CLSID folders.
But they point to non-existing locations of previous installs of VS.

e6756135-1e65-4d17-8576-610761398c3c points to:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\Debugger\msdia140.dll
3bfcea48-620f-4b6b-81f7-b9af75454c7d points to:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Packages\Debugger\msdia120.dll

To make it more complex.
The VS2017 install does contain the file. At:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Packages\Debugger\msdia140.dll
So I did a search for register entries with \msdia140.dll in the Data field. This yielded only references to locations in the (almost) empty directories below ..\Microsoft Visual Studio 14.0\...
I found no reference in the registry to the VS2017 version of the file.

By the way. The dll does work if I manually copy it to the referenced vs2015 location.


Debugging tests didn't ever produce unexpected errors for me.

@csoltenborn
Copy link
Owner

@Farwaykorse Thanks for the update - kind of as expected. It looks like VS2017 doesn't register the DIA DLLs publically any more... We'll look into this and figure out a reliable way to locate and instantiate the DIA DLL in case only VS2017 is installed - stay tuned.

@NinjaCoder It looks like your debugging problem is not related to this bug - would you mind to open a new issue and copy over your logging stuff? Thanks!

@Farwaykorse
Copy link
Author

@csoltenborn
Copy link
Owner

Thanks! Your link might indeed be useful...

Until we have figured out a reliable way to instantiate the DIA com object on VS 2017, this registry patch should also provide a workaround without the need to copy dlls around. Change file ending to .reg and install - file locations should be found afterwards. The patch assumes the VS standard installation directory - adjust if needed.

@Farwaykorse
Copy link
Author

Just confiming this registry patch is a working set (at least for the community edition of VS2017).

@jgefele
Copy link
Collaborator

jgefele commented Apr 13, 2017

jgefele added a commit that referenced this issue Apr 14, 2017
… Remove all the complexity of handling different DIA versions. (#124)
@csoltenborn csoltenborn added this to the 0.10 milestone Apr 18, 2017
@jgefele
Copy link
Collaborator

jgefele commented Apr 18, 2017

Hi @Farwaykorse,
would you please undo the registry fixes and try this build? It should fix your issues with DIA.

Cheers,
Jonas

@Farwaykorse
Copy link
Author

@jgefele Perfect!

I removed the csoltenborn's temporary register patch, before installing.
No errors and all the StackTrace links and references work again.

@bedder
Copy link

bedder commented Apr 19, 2017

@jgefele I can also confirm that that build fixed issues I was having on VS2017 Enterprise. Cheers!

csoltenborn added a commit that referenced this issue Apr 23, 2017
…d; debugging via NuGet-installed adapter is denied (#124, #126)
csoltenborn added a commit that referenced this issue May 2, 2017
…ound_in_isolated_VS2017_instance

Dependencies not found in isolated vs2017 instance (#124, #126)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants