-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Description
Summary
We want to mark our tasks sealed, but this would be an API breaking change. To justify this change we need data. So we want to collect data about MSBuild, SDK, and generally Microsoft-authored Task usage to drive this decision making.
Background and Motivation
Today tasks shipped by MSBuild and the SDK generally are not sealed. This means that folks consuming our NuGet packages can extend the Tasks and use them in their own code. This presents problems when we want to do things like enlighten our Tasks to support multithreading.
Proposed Feature
When loading Tasks for execution, we should collect metrics on the characteristics of that Task if that Task is shipped by MSBuild.
- if the Task is sealed or not
- if the Task inherits from
Microsoft.Build.Utilities.Task(our helper base class) - (once the multithreaded APIs are in) if the task directly implements IMultiThreadedTask
- (once the multithreaded APIs are in) if the task supports multithreading through the attribute-detection mechanism
In the future we may want expand the set of Task information gathered, and we may want to allow external MSBuild users (like the dotnet SDK) to add Tasks to the set of Tasks to collect this information about, so there should be some extensibility mechanism for both of these.
Alternative Designs
No response