Project System: AvailableItemName support

[davkean]

csproj/msvbproj supports <AvailableItemName> to allow adding to the choice of Build Actions. We should enable them to be dynamically added (such as via a NuGet package) and the project should be able to pick them up without a reload.

Update: Make sure we keep C++ in the loop, while the feature will automatically work for them in non-cached mode, their cached mode will need to be updated to handle it.

[sharwell]

For some reason my AvailableItemName items aren't appearing even after a project reload. See tunnelvisionlabs/antlr4cs#193. Here's a link to how these are added:

https://github.com/tunnelvisionlabs/antlr4cs/blob/master/runtime/CSharp/Antlr4BuildTasks/Antlr4.net40.targets#L55-L59

[natidea]

Adding back link to duped feedback: https://developercommunity.visualstudio.com/content/problem/31240/additional-build-actions-for-netstandard-library-p.html

[davkean]

ShowMissingItemTypes capability controls whether unknown items show up in the tree - but we still need a way to extend the list of Build Actions in the properties window.

[Neutrino-Sunset]

This functionality is necessary to make it possible to do things like copy files to the output directory, which laughably, are impossible in Visual Studio without resorting to batch files (or a post build event which is a batch file by another name).

E.g. You have a project subdirectory 'Libs' containing binary dependencies, you want that output to your output directory. If you just select build type 'Content' and 'Copy to output directory' it will end up in $(OutDir)/Libs where your binary dependencies will not be resolved.

The 'fix' was to add this to your project file:

   <ItemGroup>
      <AvailableItemName Include="RootContent">
         <Visible>false</Visible>
      </AvailableItemName>
   </ItemGroup>
   <Target Name="AfterBuild">
      <Copy DestinationFolder="$(OutputPath)" SourceFiles="@(RootContent)" SkipUnchangedFiles="true" />
   </Target> 

...which enabled you to mark the files as 'RootContent' whereupon they would get copied to the output directory.

Now even this hack of a workaround is broken with no mention of an alternative. How do I copy files to my output directory now?

[Neutrino-Sunset]

This is compounded by the fact that build events are now completely broken too as project environment variables are not expanded, so even using a batch file is now impossible either.

dotnet/sdk#677

Honestly the Dotnet Core / VS2017 tooling is an absolute train wreck.

[kzu]

@Neutrino-Sunset the easiest way to do that is with something like this:

<ItemGroup>
  <Libs Include="Libs\**\*.*" />
  <Content Include="@(Libs)">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    <TargetPath>%(Filename)%(Extension)</TargetPath>
  </Content>
</ItemGroup>

I consider build events a super old legacy thing that was brought forward for backs compat mostly, but using built-in MSBuild constructs everything is extremely easy.

For example, the elements above automatically integrate with clean, incremental build/copy, etc., without you having to do anything.

And also, it works all the way back to the earliest MSBuild versions, nothing to do with .NET Core or VS2017 honestly.

[Neutrino-Sunset]

That doesn't work either.

Firstly it ouputs the Libs directory to the output directory even though the TargetPath '%(Filename)%(Extension)' should not do this. Secondly it doesn't delete the Libs directory when you clean the project.

This does work, although it's not pretty and it took time to work out that I'd rather have spent doing something useful.

   <ItemGroup>
      <Libs Include="Libs/*.*" />
   </ItemGroup>   

   <Target Name="CopyLibs" AfterTargets="Compile">
      <Copy SourceFiles="@(Libs)" DestinationFolder="$(OutDir)" />
   </Target>

   <Target Name="DeleteLibs" AfterTargets="Clean">
      <Delete Files="$(OutDir)%(Libs.Filename)%(Libs.Extension)" />
   </Target>

Thanks for putting me on a useful track though.

[sharwell]

📝 When implementing this feature, the following should be verified:

1. Items given a type which corresponds to an AvailableItemName should not be also added as None
2. Items given a type which corresponds to an AvailableItemName should show up in Solution Explorer

[davkean]

1. Is quite difficult to do - due to the globbing in the SDK. I think we'll want a different approach where we merge item types.

[sharwell]

@davkean 2 is really the important item. If 1 is a "must" for some particular project, they can just use <EnableDefaultNoneItems>False</EnableDefaultNoneItems>.

[iskiselev]

Is it possible to see in solution explorer currently items with non-standard type? At least on VS 2017.4, adding to PropertyGroup <ShowMissingItemTypes>true</ShowMissingItemTypes> does not help for it. At the same time I was able to populate custom Build Action in properties selector dropdown using suggestion from (#2160), but as soon as I change type to my custom item disappears from Solution Explorer. It there any workaround currently available?

[davkean]

@iskiselev To turn on the capability you add the following:

<ItemGroup>
    <ProjectCapability Include="ShowMissingItemTypes" />
</ItemGroup>

Note that this is an experimental feature.

[davidwengier]

Changes to enable AvailableItemName support in CPS are in progress (Internal PR). An additional PR will be created to finalize support in this repo once that is complete.