How to correctly derive from TrackedVCToolTask and reference Microsoft.Build.CPPTasks?

[snalexp]

Hi,

We have a tool and a custom task that runs it, and after investigating VS 2022 17.1 Preview (msbuild version 17.1.0-preview-21526-01+a80e2274f for .NET Framework, 17.1.0.52601), it fails to load and run during a build.

The tool we are invoking, banana.exe, receives, for example, a foo.yml file as input, and generates a foo.h and foo.cpp pair of files, which are then included in the rest of the regular CPP build of the projects.

The message I get is:

"Project.sln" (default target) (1) ->
"Project.vcxproj" (default target) (2) ->
(BananaToolCompile target) ->
  MSBuild\2022\banana-tool.targets(39,3): error MSB4062: The "BananaTool" task could not be loaded from the assembly MSBuild\2022\bin\Build.Tasks.dll. Could not load file or assembly 'Microsoft.Build.CPPTasks.Common, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. 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. [Project.vcxproj]

The same project builds without issue using 17.0 Current, Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET Framework, 17.0.0.52104.

We have maintained this task since 2016 so it has survived several updates to VS/MSBuild, but seems to have come unstuck.

My understanding is that msbuild prior to 17.0 had a binding redirect in the config file for the Microsoft.Build.CPPTasks.Common assembly, so we did not have to rebuild Build.Tasks assembly for each point release of MSBuild.

I also understand that this has been removed from 17.0 in order to allow older toolchains to be mixed with a newer MSBuild (i.e msbuild 17 with MSVC cl etc 15 or something).

Therefore our reference to Microsoft.Build.CPPTasks.Common 17.0 is no longer redirected to Microsoft.Build.CPPTasks.Common 17.1 and the failure to load/build in the preview is in line with expectations.

I gained this by reading:

• Issue 6248
• PR 6321
• Developer Community issue

I own these tasks, so changes can be made.

From the Developer Community issue I tried changing our task code, which derives from TrackedVCToolTask, to reference Microsoft.Build.CPPTasks.Common.Base 17.0 instead.

Unfortunately this caused the task to start failing in both Current and Preview instances. The message is similar:

"Project.sln" (default target) (1) ->
"Project.vcxproj" (default target) (2) ->
(BananaToolCompile target) ->
  MSBuild\2022\banana-tool.targets(39,3): error MSB4062: The "BananaTool" task could not be loaded from the assembly MSBuild\2022\bin\Build.Tasks.dll. Could not load file or assembly 'Microsoft.Build.CPPTasks.Common.Base, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. 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. [Project.vcxproj]

Also from the Developer Community issue, I tried adding

<UsingTask TaskName="SetEnv" AssemblyFile="$(VCTargetsPath)Microsoft.Build.CPPTasks.Common.Base.dll"/>

to our banana-tool.targets file.

This didn't help.

---

As mentioned earlier, the banana.exe tool receives a .yml file as input. This file can refer to other .yml files, which the tool will open and interpret.

I believe we derive from TrackedVCToolTask to ensure that the file tracker is invoked, so the tlog files contain the correct inputs and outputs and ensure the tool is not executed when not needed, but is when the input has changed, or the outputs are missing.

The overall goal is:

• Straightforward MSBuild/Visual Studio integration using targets/props etc. for team members
• Reliable full and incremental builds (no extra work when not needed, and correct execution when things are out of date etc.)
• Works with VS 2017/2019/2022 both in-IDE and command line(msbuild.exe) builds (If the "VS2019 toolset in VS2022 IDE can also be supported, that would be good)

Question 1

Is this the right way to approach the problem anymore? The reason for choosing TrackedVCToolTask as the basis has been somewhat lost to time, but it was likely after reading Inside the Microsoft Build Engine book, looking at other projects (e.g. VisualD), and experimentation. This was originally authored around 2015/16 so it's possible that there is a better recommendation to achieve what we want?

Question 2

If using TrackedVCToolTask is the right way to author the Task, what is the correct way to ensure it loads and executes in MSBuild 17.0 and subsequent point releases?

Thanks in advance,

[snalexp]

This question has broadly been answered over on Developer Community.

I won't reproduce all the details of the thread, but the gist from it is:

Quoting Olga Arkhipova [MSFT]:

Having redirection to the latest Microsoft.Build.CPPTasks.Common.dll in VS 2019 was causing problems in a number of scenarios. In VS 2022 we created another assembly can be used for referencing cpp tasks classes and which will not change the version untill next major Visual Studio release.

It you own the tasks that reference Microsoft.Build.CPPTasks.Common.dll, please change them to reference
Microsoft.Build.CPPTasks.Common.Base.dll - its content is identical to Microsoft.Build.CPPTasks.Common.dll, but its version will remain 17.0 in all releases of VS 2022, while version of the Microsoft.Build.CPPTasks.Common.dll will match the VS release (17.1, 17.2, etc.).

To ensure that Microsoft.Build.CPPTasks.Common.Base.dll is found when loading the extension tasks dll:

• install your tasks dll in \MSBuild\Microsoft\VC\v170
  or
• make the build using one of the tasks from Microsoft.Build.CPPTasks.Common.Base.dll before using a task that reference it. This can be achieved by adding in one of your extension .props files:

<UsingTask TaskName="SetEnv" AssemblyFile="$(VCTargetsPath)Microsoft.Build.CppTasks.Common.Base.dll"/>