1

I'm trying to make Roslyn/MSBuildWorkspace work on some older .NET Framework projects. Those occasionally have COM references, some of them incorrect. Compiling in Visual Studio works with warnings:

2>------ Rebuild All started: Project: ResolveComReference, Configuration: Debug Any CPU ------
2>C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2977,5): warning MSB3284: Cannot get the file path for type library "ffffffff-0000-0000-0000-0000000fffff" version 3.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
2>C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2977,5): warning MSB3305: Processing COM reference "VAccessLib" from path "C:\Program Files (x86)\Actian\Zen\bin\ACBtr732.ocx". Type library importer has encountered an interface not derived from IUnknown: 'ISWData'.
2>  ResolveComReference -> C:\ResolveComReference\bin\Debug\ResolveComReference.dll

Calling MSBuild.exe (without any parameters) compiles the project with warnings as well, they are shown in the ResolveComReferences section of verbose output.

But doing it from my code fails (the code is the usual: workspace = MSBuildWorkspace.Create(); var solution = await workspace.OpenSolutionAsync(solutionPath);).

Msbuild failed when processing the file 'C:\ResolveComReference\ResolveComReference.csproj' with message: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets: (2977, 5): The "ResolveComReference" task could not be instantiated from "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Could not load file or assembly 'Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Msbuild failed when processing the file 'C:\ResolveComReference\ResolveComReference.csproj' with message: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets: (2977, 5): The "ResolveComReference" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.

and then additionally because of a project reference

Found project reference without a matching metadata reference: C:\TestProjects\_EmptyProject48\code.csproj

All this happens using code from the project template "Standalone Code Analysis Tool". Updating the referenced nuget packages doesn't help.

How do I make it work?

I think I could work around this by using AdhocWorkspace everywhere instead and manually parsing the sln and csproj files (see LegacyWorkspaceLoader), but I really rather not, especially because I see MSBuild.exe working as expected on the same solution.

Example COMReference item:

    <COMReference Include="some_unexisting_library">
      <Guid>{FFFFFFFF-0000-0000-0000-0000000FFFFF}</Guid>
      <VersionMajor>3</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>aximp</WrapperTool>
      <Isolated>False</Isolated>
    </COMReference>
Tymur Gubayev
  • 468
  • 4
  • 14
  • This has little to do with COMReference, it can't find Microsoft.Build.Tasks.Core.dll. File-not-found, the most basic mishap. Be sure to add the Nuget package for it. – Hans Passant Feb 07 '23 at 18:44
  • I can see in the Modules window when I set a breakpoint that the `Microsoft.Build.Tasks.Core.dll` is loaded from the VS folder – Tymur Gubayev Feb 07 '23 at 18:50
  • That makes little sense for a "standalone tool", nor does the exception message complain about finding the wrong version. Use the Nuget package. – Hans Passant Feb 07 '23 at 18:55
  • Yes, both the name and the exception are confusing and neither one was my choice :) – Tymur Gubayev Feb 07 '23 at 18:56
  • If by the "nuget package" you mean the "Microsoft.Build.Tasks.Core", adding it only changes where the dll is loaded from (now it's the app folder instead of VS), errors remain the same. – Tymur Gubayev Feb 07 '23 at 18:59
  • Sorry, it is actually slightly different: "Msbuild failed when processing the file ... Cannot get the file path for type library "ffffffff-0000-0000-0000-0000000fffff" version 3.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))". So I get to see why it fails, still don't get it compiled. – Tymur Gubayev Feb 07 '23 at 19:10

0 Answers0