Skip to content

Deprecate and restrict non-MSBuild TaskFactory implementations #12347

@rainersigwald

Description

@rainersigwald

Summary

Deprecate the public interfaces ITaskFactory and ITaskFactory2 and prevent usage of custom task factories that are not internal to MSBuild. The change should error if a custom task factory is specified, gated behind a new change wave opt-out.

Background and Motivation

Currently, users may implement custom TaskFactories by implementing ITaskFactory or ITaskFactory2 and referencing them in project files. However, these custom implementations are not compatible with upcoming multithreaded MSBuild changes. There is little known usage of this extensibility and maintaining support for arbitrary factories will block future engine work.

Proposed Feature

  1. Annotate ITaskFactory and ITaskFactory2 as deprecated in documentation and code comments.
  2. Implement logic (in src/Build/Instance/TaskRegistry.cs) to error if a TaskFactory type is specified that is not internal to MSBuild. Only allow built-in factories (e.g., CodeTaskFactory, AssemblyTaskFactory).
  3. Gate this error behind a new change wave so that users can opt-out temporarily if their builds depend on custom TaskFactories.
  4. Document the change and migration guidance.
  5. Add tests to verify the error is thrown behind the change wave and not otherwise.
  6. Announce the breaking change and solicit feedback from the community.

Reference: ChangeWaves-Dev.md for implementation guidance on change waves.

Alternative Designs

Alternative approach: Instead of immediately erroring, emit a warning for one change wave before making it an error in the next wave, giving users more time to migrate. Could also restrict only the most problematic custom factories first and widen the restriction over time. This doesn't seem worthwhile though since we're not aware of any usage.

Metadata

Metadata

Assignees

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions