Emit clearer error for built-in tasks that don't work on .NET Core

[rainersigwald]

Not all tasks in Microsoft.Build.Tasks.Core.dll are present in .NET Core MSBuild; some weren't ported because of API limitations at the time and some just aren't done yet.

It'd be nice if you got a clear error indicating this, rather than a mysterious one like

C:\Program Files\dotnet\sdk\2.1.301\Microsoft.Common.CurrentVersion.targets(2725,5): error 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 <UsingTask> 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.

[rainersigwald]

This was done specifically for ResolveComReference in #3987. That model could be extended to all the tasks we don't build for Core.

Marking as up-for-grabs since we'd take contributions to build more stubs.

[santoshyadavdev]

Hi @rainersigwald,

Will take this up.

[kendrahavens]

A user on an unrelated ticket mentioned using the workaround documented here: https://stackoverflow.com/questions/47062203/net-core-error-on-build-error-msb4062-microsoft-build-tasks-resolvecomreferenc.
Should we have official guidance on this?

[rainersigwald]

@kendrahavens for COM specifically? Do you have suggestions over https://docs.microsoft.com/en-us/visualstudio/msbuild/resolvecomreference-task?view=vs-2019#msb4803-error?

[jrdodds]

@rainersigwald Please assign this issue to me.

Updated Notes:

I will create stubs for the following tasks based on how the ResolveComReference task was stubbed.

• AL
• AspNetCompiler
• GenerateBootstrapper
• GenerateTrustInfo
• GetFrameworkSdkPath
• RegisterAssembly
• ResolveComReference
• ResolveNativeReference
• UnregisterAssembly
• UpdateManifest
• WinMDExp

Additionally, AppDomainIsolatedTask (base class of AppDomainIsolatedTaskExtension) is not used in ".NET Core MSBuild" and will be included in the Utilities project for '.NETFramework' only.

[jrdodds]

PR #3987 includes a change in ref/ (specifically in ref/Microsoft.Build.Tasks.Core/netstandard/Microsoft.Build.Tasks.Core.cs) but ref/ is not a part of the public dotnet/msbuild repo.

Has the ref/ directory been replaced by dotnet/source-build-reference-packages (src/referencePackages/src/microsoft.build.tasks.core/17.4.0/ref/netstandard2.0/Microsoft.Build.Tasks.Core.cs)? It looks like there is an automated system for updating reference packages. How are changes made or propagated?

[rainersigwald]

PR #3987 includes a change in ref/ (specifically in ref/Microsoft.Build.Tasks.Core/netstandard/Microsoft.Build.Tasks.Core.cs) but ref/ is not a part of the public dotnet/msbuild repo.

Has the ref/ directory been replaced by dotnet/source-build-reference-packages (src/referencePackages/src/microsoft.build.tasks.core/17.4.0/ref/netstandard2.0/Microsoft.Build.Tasks.Core.cs)? It looks like there is an automated system for updating reference packages. How are changes made or propagated?

The ref/ stuff has been replaced by .NET SDK-integrated package validation. For this specific change, the API surface should only increase (with the new-to-core types), which should not cause any errors. If you encounter errors highlight them in the PR and we can consider the best way forward (we can add exceptions if there's something that's technically breaking but reasonable to do).

[jrdodds]

The PR fails to build because base classes are different for the tasks.