Error "Class not registered" when building inject_debug_resources.vcxproj

[briansull]

Here is the relevent portion of my builds log file:
e:\fxkit\coreclr\bin\Logs\CoreCLR_Windows_NT__x64__Checked.log

57>CustomBuild:
     coreclr
     Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25019 for x64
     Copyright (C) Microsoft Corporation.  All rights reserved.
     
     daccess.cpp
     Microsoft (R) CLR External Data Access Data Table Generator Version 0.3
     Copyright (C) Microsoft Corp.  All rights reserved.
     
     BUILDMSG: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {3BFCEA48-620F-4B6B-81F7-B9AF75454C7D} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
        at Dia.Util.DiaFile..ctor(String pdbFile, String dllFile)
        at PdbSymbolProvider..ctor(String symbolFilename, String dllFilename)
        at Shell.DoMain(String[] args)
        at Shell.Main(String[] args)
57>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 1. [E:\fxkit\coreclr\bin\obj\Windows_NT.x64.Checked\src\dlls\mscoree\coreclr\inject_debug_resources.vcxproj]
57>Done Building Project "E:\fxkit\coreclr\bin\obj\Windows_NT.x64.Checked\src\dlls\mscoree\coreclr\inject_debug_resources.vcxproj" (default targets) -- FAILED.

[briansull]

It looks like the following "Important" instruction is responsible for this error:

• Important: You must have the msdia120.dll COM Library registered in order to build the repository.
• This binary is registered by default when installing the "VC++ Tools" with Visual Studio 2015 (but apparently not on VS 2017)
• You can also manually register the binary by launching the "Developer Command Prompt for VS2017"
• with Administrative privileges and running:

regsvr32.exe "%VSINSTALLDIR%\Common7\IDE\msdia120.dll"

However actually performing this step successfully is problematic.

[briansull]

In order for that command to be successful it must be run in a 32-bit command window and not the default 64-bit command window.

Use the following to start a 32-bit command window:

%SystemRoot%\sysWow64\cmd.exe

[briansull]

Ping. Hit this issue again

[mfilippov]

I have same issue, @briansull thank you for workaround.

[sandreenko]

Hit the issue today.

[jashook]

I hit this issue as well. Work around fixed the issue thank you @briansull

[stop-cran]

I performed a search in registry of mentioned CLSID {3BFCEA48-620F-4B6B-81F7-B9AF75454C7D} and changed all paths for it on C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\msdia120.dll.

Before that this CLSID pointed to dll by inexistent path (maybe it was accidentally deleted).

After editing registry the error disappeared.

[RussellHaley]

ping!
I see now there is an "Important" tag in the instructions already (the shame!), perhaps someone can add the class ID error so that when it occurs the user has reference in the instructions?
https://github.com/dotnet/coreclr/blob/master/Documentation/building/windows-instructions.md#environment

** Note: if you receive the following error, you have failed to register the class noted above:

Retrieving the COM class factory for component with CLSID {3BFCEA48-620F-4B6B-81F7-B9AF75454C7D} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

**

[vancem]

Note that the root cause for this is that there is a tool called DacTableGen in the microsoft.dotnet.buildtools.coreclr package which uses a COM object to open symbols, and is using an old version of this library (msdia120.dll). This was current in VS2015 but VS2017 has moved on to msdia140.dll (which has a different COM GUID.

The fundamental problem is that DacTableGen should bundle and install anything that it uses, but instead is 'piggybacking' on the fact that VS installs this COM object. That was true for VS2015 but not for VS2017.

It turns out that VS2017 DOES have this msdia120, however it does not register it. Thus you can work around it by using the instructions

regsvr32.exe "%VSINSTALLDIR%\Common7\IDE\msdia120.dll"  

from an administrative prompt.

However the real fix is to update microsoft.dotnet.buildtools.coreclr so that

• We upgrade the tool to use msdia140.dll (this will fix the problem since VS2017 registers this version, but it will break if VS moves on and DacTableGen does not).

• Modify DacTableGen so that it includes msdia140.dll and does not use COM to activate what it needs (there is a fairly standard way of doing this that a number of tools that manipulate PDBs use). (This will prevent it forever in the future).

We have located the source code for this in the ProjectK branch in VSTS. (source for DacTableGen in src\NDP\clr\src\ToolBox\SOS\DacTableGen and nuget specifications in src\NDP\FxCore\src\Packages\Microsoft.DotNet.BuildTools.CoreCLR). However this branch is now old enough that it will take some time to get the build building again so we can rebuild the package.

In the mean time I will be putting a check in the build.cmd file so that it gives this work-around (which only has to be done once per machine) until such time as we fix the package.

See dotnet/coreclr#14948 for the change to build.cmd to make the work-around obvious.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.