How to delete a list of files with MSBuild Delete task without using ItemsGroup

Question

I know, a list of files can be deleted using MSBuild Delete task with the help of <ItemsGroup>. As mentioned here. However is there a way to do the same without using the .

Basically can delete task do something similar to <Exec Command="del /f /q *.pdp"/>

Answer 1

It seems what you want is something like:

<Target Name="TestDelete" AfterTargets="xxx">
    <Delete Files="$(Outputpath)*.pdb"/>
</Target>

But as I know the wildcard is not recognized in msbuild task parameters.

So the answer is negative I'm afraid. I recommend you use wildcard in Items to refer to the list of files.

Check MSBuild Items and MSBuild Tasks.In official document, only Items is clearly stated that it supports for wildcards.

Also, you can check this similar issue.

Update:

Actually not sure the real reason of the particular design. I've just read the Task Writing document. And write a simple MyDelete task to research.

public class MyDelete:Task
    {
        [Required]
        public string MyProperty { get; set; }

        public override bool Execute()
        {
            // Log a high-importance comment
            Log.LogMessage(MessageImportance.High,
                "MyDelete Task has delete files: \"" + MyProperty + "\".");
            return true;
        }
    }

Then I add the script below into project file:

<UsingTask TaskName="MyMessage.MyDelete"
        AssemblyFile="MyDelete.dll"/>

  <Target Name="MyTarget" AfterTargets="build">
    <ItemGroup>
      <MyItem Include="$(Outputpath)*.*"/>
    </ItemGroup>
    <MyDelete MyProperty="$(Outputpath)*.*"/>
    <MyDelete MyProperty="@(MyItem)"/>
  </Target>

The build output should be like:

My guess is for most tasks, the property is string, so the input which contains a wildcard is a string variable "path*.*", which can't be recognized by the code of the task directly.

But for Item, according to document：Item types are named lists of items that can be used as parameters for tasks. So the input is string like "xxx;xxx;xxx..." which perform well.

My update is just to make a deep research, hard to answer the particular reason about the design. I think if you do want to know the design reason, you may need to ask some help from who supports the product by this link.