Description
Summary
Writing modular encapsulated functionality in MSBuild is sometimes difficult. A given operation may require a chain of targets where the individual targets aren't standalone and are expected to be used in concert. But all targets available on a project can be invoked on the project.
If the targets on a project are thought of being like class methods, all the methods are public.
It would be useful to have support for being able to make a target 'Internal' to a project, i.e. not public.
(If this has been proposed before, I searched and failed to find the prior issue or feature request.)
Background and Motivation
A common pattern in MSBuild is a target that defines a chain of targets and has no body, e.g.
<Target Name="DoSomething" DependsOnTargets="_DefineSomethingProps;_PrepareSomething;_DoSomething;_FinallySomething" />
Each of the targets in the chain can have error checking and BeforeTargets
, AfterTargets
, and/or DependsOnTargets
attributes to ensure they all run and all run in the correct order, regardless of which target is invoked.
But it may also be desirable to prevent the _DefineSomethingProps
, _PrepareSomething
, _DoSomething
, and _FinallySomething
targets from being invoked from outside the project. The DoSomething
target would be the exposed public 'command'.
Proposed Feature
Introduce a new optional attribute for the Target
element. The attribute might be named Internal
, expect a Boolean value, and default to false
when the attribute is not present. Existing code would not be impacted.
<Target Name="_DefineSomethingProps" Internal="true" ...
When Internal
is true
, MSBuild will prevent the target from being invoked from outside the project.
- Passing the name of an 'internal' target via the
/t
switch of the command line should be an error. - Passing the name of an 'internal' target via the
Targets
attribute of theMSBuild
task should be an error.
Alternative Designs
No response