Confusing error when using COMReference on Core

[rainersigwald]

From @fubar-coder on Tuesday, 23 April 2019 07:16:19

I get an error which seems to be caused by the following COMReference project item:

  <ItemGroup Condition=" '$(TargetFramework)' == 'net461' and '$(OS)' == 'Windows_NT' ">
    <COMReference Include="ADOX.dll">
      <Guid>00000600-0000-0010-8000-00aa006d2ea4</Guid>
      <VersionMajor>6</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <WrapperTool>tlbimp</WrapperTool>
      <Lcid>0</Lcid>
      <Isolated>false</Isolated>
    </COMReference>
  </ItemGroup>

The error message roughly translates to something along the lines: The "ResolveComReference" task couldn't be executed, because MSBuild couldn't create or connect to a task host with runtime "CLR4" and architecture "x86".

I also attached the build log.

build-log.zip

Copied from original issue: dotnet/installer#1690

[rainersigwald]

From @Pilchie on Tuesday, 23 April 2019 16:24:09

@rainersigwald do you know the state of COMReference in the SDK?

[rainersigwald]

From @rainersigwald on Tuesday, 23 April 2019 18:07:39

It's not expected to work, but it should fail in a clearer way than this. I think that's a bug for Microsoft/MSBuild; I'll move this and describe what the problem is there.

[rainersigwald]

COM reference resolution currently only works when building with MSBuild.exe. That's tracked by #3986. You should be able to build successfully with MSBuild.exe (targeting .NET Core 3.0).

This error is very confusing; we should instead give the error added in #3987, which should make the underlying problem clearer. This issue tracks the bad error, which I think is related to this:

https://github.com/Microsoft/msbuild/blob/64a5b6be6d4c1a45c02537a08dca8dd1db09f7f2/src/Tasks/Microsoft.Common.CurrentVersion.targets#L3019-L3043

I think we're trying to load a task in a specific TaskHost environment that we can't satisfy, which means we can't emit the error from the new task.

[rainersigwald]

Reproed with @Forgind; this only happens when PlatformTarget is x86.

[jzabroski]

@rainersigwald Could use a little help understanding the problem and fix here. I am switching to JetBrains Rider on my home computer to give it a try, and when I build a project with ADOX.dll reference, I get errors like the one described here.

Microsoft.Common.CurrentVersion.targets(2729, 5): [MSB4062] The "Microsoft.Build.Tasks.ResolveComReference" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

for the following MSBuild csproj snippet:

  <ItemGroup Condition=" '$(TargetFramework)' == 'net461' and '$(OS)' == 'Windows_NT' ">
    <COMReference Include="ADOX.dll">
      <Guid>00000600-0000-0010-8000-00aa006d2ea4</Guid>
      <VersionMajor>6</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <WrapperTool>tlbimp</WrapperTool>
      <Lcid>0</Lcid>
      <Isolated>false</Isolated>
    </COMReference>
  </ItemGroup>

I then right clicked on the project, and explicitly added "Microsoft ADO Ext. 6.0 for DDL and Security 6.0.0", which generated nearly identical info: it added <EmbedInteropTypes>True</EmbedInteropTypes>.

Is the only way to get this to work to install .net core 3.0+? I'm trying that now but I couldn't understand

I think we're trying to load a task in a specific TaskHost environment that we can't satisfy, which means we can't emit the error from the new task.

And - I take it the improvements in the latest MSBuild assembly loader solve this problem, too?

Edit: Ha. Re-reading the issue, I see @fubar-coder reported it and we're both literally referring to the same xml in the same project.

[jzabroski]

After installing .NET SDK 3.1.101 x64, I now get this error:

Microsoft.Common.CurrentVersion.targets(2726, 5): [MSB4216] Could not run the "ResolveComReference" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files\dotnet\sdk\3.1.101\MSBuild.exe" exists and can be run.

I don't quite understand this message - not being difficult.

1. the requested runtime and/or architecture are available on the machine - checked using https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed#use-powershell-to-check-for-a-minimum-version shows I have .NET Framework 4.8 installed, and I have the Developer Pack for .NET Framework 4.6.1

   (Get-ItemProperty "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release

   528040
   

2. that the required executable "C:\Program Files\dotnet\sdk\3.1.101\MSBuild.exe" exists and can be run - ran following in PowerShell:

   ls "C:\Program Files\dotnet\sdk\3.1.101\MSBuild.*"

       Directory: C:\Program Files\dotnet\sdk\3.1.101
   
   Mode                LastWriteTime         Length Name
   ----                -------------         ------ ----
   -a----       12/18/2019   1:15 AM         153587 MSBuild.deps.json
   -a----       12/19/2019  10:31 PM         696184 MSBuild.dll
   -a----       12/19/2019  10:29 PM            154 MSBuild.runtimeconfig.json
   

Is this supposed to be looking for an MSBuild.exe or is it a typo in the error message?

[jzabroski]

I believe this line is incorrect in .NET Core context:
https://github.com/microsoft/msbuild/blob/81d9a23b505474a1e7fff3fad86fa5ba2c475523/src/Build/Instance/TaskFactories/TaskHostTask.cs#L568

I will open a ticket to discuss this message improvement separate from whether this issue fixes the originally reported problem.

[rainersigwald]

@jzabroski This bug (the confusing error message) should be fixed in MSBuild 16.5/SDK 3.1.200, which isn't out yet.

[jzabroski]

@rainersigwald Sorry - but, can you (a) point me to the fix? (b) explain to me if there is a workaround / what the correct error message should be here?

And thanks for your help.

[Forgind]

The change is here.

rainersigwald recommended this error message:
The task "{0}" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild. See https://aka.ms/msbuild/MSB4803 for further details.
where {0} refers to the ResolveComReference task.

[jzabroski]

@Forgind Thanks for all your amazing work, and thanks @rainersigwald for your leadership in making this a much more usable/better product overall. Very impressed.

[jzabroski]

@jzabroski This bug (the confusing error message) should be fixed in MSBuild 16.5/SDK 3.1.200, which isn't out yet.

@rainersigwald Is there any way I can stick a check for MSBuild at top of a .NET SDK project? I have stayed away from putting build targets in .NET SDK projects, with the assumption it isn't smart to do so, and put targets in a build.targets file instead. However, it would be nice to have an InitialTargets="MSBuildMinimumVersionCheck" at the top of the project file to encourage people working on my open source project to use the latest version of the SDK/MSBuild.

I was thinking MSBuildVersion and MSBuildRuntimeType?

[rainersigwald]

@jzabroski Yes, you can add InitialTargets to SDK-style projects just as you can with legacy projects. You might be interested in defining the target in a Directory.Build.targets so it gets imported into many projects in your solution. The properties you mentioned are the likely candidates for such a check. You might also like the version-comparison property functions from #4911--but note that since they're new, if someone's using an old MSBuild they may not be able to parse a file that uses them. Until they get everywhere you'd have to guard their use (ironically behind an MSBuild-version version check . . . so probably not actually helpful to you today).

[jzabroski]

@rainersigwald I like where you're going. Saving the world from one footgun at a time. Somewhere on the Redmond campus there should be a slab of Golden Foot dedicated to your MSBuild sanitization. If refactoring MSBuild isn't an athletic achievement, I don't know what is.