Detect architecture-specific task assemblies and infer taskhost

[rainersigwald]

Today, if you have a task that is built for 32-bit or 64-bit, but does not specify architecture in its UsingTask, you get an error message:

S:\work\cross-arch-tasks\TaskUse.proj(8,5): error MSB4062: The "Task32" task
could not be loaded from the assembly
S:\work\cross-arch-tasks\Task32\bin\Debug\net472\Task32.dll. Could not load file
or assembly
'file:///S:\work\cross-arch-tasks\Task32\bin\Debug\net472\Task32.dll' or one of
its dependencies. An attempt was made to load a program with an incorrect
format. 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.

This isn't very actionable.

MSBuild could examine the task assembly before loading it and infer an Architecture requirement if the assembly isn't MSIL. If we don't infer, we could at least emit a more-specific error message like

The task assembly XXX specifies the x86 architecture but the currently-loaded .NET runtime is x64. Consider adding an Architecture requirement to the UsingTask.

[rainersigwald]

Repro project: msbuild6357.zip

Build the solution, then build TaskUse.proj in 32- or 64-bit MSBuild. The task compiled for the other assembly will fail.

[AArnott]

if the assembly isn't MSIL

Strictly speaking, compiling with the x64 or x86 platforms still produces MSIL. The only change is to a flag in the PE header I think.

[marcpopMSFT]

@clairernovotny since you're working on the documentation we want to send out to help customers get their tasks 64bit compliant. This is probably something we should do in the 17.0 timeframe.

[clairernovotny]

This makes sense to me. @KathleenDollard mentioned this to me earlier today.