The behavior is similar to Content: if the packed items have CopyToOutputDirectory, they become part of the build output kind. Otherwise, they are treated like content with a default CodeLanguage that matches the project's default language source extension. This makes the most sense and would in most cases not require any futher metadata annotations.

Tests ensure that the overriding of CodeLanguage, TargetFramework and other metadata still work as expected.

Adding support for EmbeddedResource packing (as supported by SDK pack) would have involved more copy/paste of exisitng MSBuild code, and that was becoming a red herring for maintainability.

Taking inspiration from the awesome flexibility of the roslyn editor config generation from MSBuild (see https://github.com/dotnet/roslyn/blob/master/src/Compilers/Core/MSBuildTask/Microsoft.Managed.Core.targets#L122-L154), we can now make it not only straightforward to add new item types for pack inference, but do so in a simple and maintainable way.

The remaining built-in content type items will be added in separate commits to showcase how that will be done moving forward, based on the items at https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#including-content-in-a-package.

The test showcases how the mechanism is itself extensible (which is what we basically did with the new built-in ones) and how the same rules can be applied to any custom item types.

Corresponding PackXXX properties were added for each new item type, so they can also be defaulted to Pack=true (or false) automatically like the existing Content/Compile/None/EmbeddedResource.

Dev > Main