Producing an MSBuild task package

[natemcmaster]

Can we get better support for projects designed to produce MSBuild tasks?

Pain points

• packing. You can get a task assembly and files into the package, but requires deep understanding of how to alter the default layout of the package in csproj.
  • TargetFrameworks. A package that only has task assemblies/targets is compiled for net46 and netcoreapp1.0, but the package itself can be compatible with any project, regardless of its TFM.
• task references. When loading a task assembly, MSBuild does not use the NuGet cache to find dependencies. This means we have to package assemblies to sit side-by-side on disk so task loading works.
• tasks with native dependencies. Never been able to make this work.

Workarounds
Task assembly projects end up looking like this

  <PropertyGroup>
    <!--
      The netstandard1.0 and net45 TFMs don't actually compile tasks.
      Only here so the generated nuspec includes the TFM so it appears as "compatible" on NuGet.org
      and in VS NuGet GUI.

      netstandard1.6 => loaded on dotnet.exe
      net46 => loaded on MSBuild.exe
    -->
    <TargetFrameworks>netstandard1.6;net46;netstandard1.0;net45</TargetFrameworks>
    <!-- Be quiet NuGet. I don't want assemblies in lib/ and yes I'm sure this is right. -->
    <NoPackageAnalysis>true</NoPackageAnalysis>
    <!-- forces SDK to copy dependencies into build output to make packing easier -->
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
    <BuildOutputTargetFolder>tools</BuildOutputTargetFolder>
  </PropertyGroup>

  <ItemGroup>
    <!-- ensure nuspec doesn't contain any package references as we bundle their assemblies in our package -->
    <PackageReference Update="@(PackageReference)" PrivateAssets="All" />
  </ItemGroup>

  <!-- 
    Copy dependencies into the tools/$(TargetFramework)/ package folders.
    MSBuild does not resolve task runtime dependencies from PackageReference
  -->
  <Target Name="PackTaskDependencies" BeforeTargets="GenerateNuspec">
    <!--
    The include needs to happen after output has been copied to build output folder
    but before NuGet generates a nuspec.
    -->
    <ItemGroup>
      <_PackageFiles Include="bin\$(Configuration)\*\Newtonsoft.Json.dll;bin\$(Configuration)\*\NUglify.dll">
        <PackagePath>tools\%(RecursiveDir)</PackagePath>
        <Visible>false</Visible>
        <BuildAction>Content</BuildAction>
      </_PackageFiles>
    </ItemGroup>
  </Target>

Some MSBuild task projects in the wild:

madskristensen/BundlerMinifier
aspnet/BuildTools
natemcmaster/Yarn.MSBuild

[livarcocc]

cc @emgarten @rohit21agrawal

[rohit21agrawal]

we already added some extension points that should make this easier : NuGet/NuGet.Client#1255

We can't make a generic Task package type since all packages would differ widely. Do you have any concrete suggestions on what you would like to see that would make it easier for you to create task packages?

[natemcmaster]

In a world of unlimited resources, I'd love to see this:

<Project Sdk="Microsoft.Build.Task">
</Project>

Microsoft.NET.Sdk is geared towards runtime packages, not MSBuild task packages. Packages designed to carry MSBuild tasks are fundamentally different from packages that only carry runtime bits.

[natemcmaster]

@rohit21agrawal if you're looking for short-term fixes to the pack task...

One of the problems today is that package authors have to choose between nuspec and csproj=>nuspec generation. Keeping csproj and nuspec aligned is difficult, esp. for users new to MSbuild. Wrangling MSBuild to make csproj=>nuspec generation work right is difficult, even for advanced MSBuild users. I had to read NuGet's source code to figure some of this out.

Anything you can do to make nuspec + csproj easier would help with this ask.

One idea:
Make all msbuild properties available in nuspec. Currently you have to manually marshal these via <NuspecProperties>

<package>
  <metadata>
    <id>${MSBuild.PackageId}</id>
    <version>${MSBuild.PackageVersion}</version>
  </metadata>
</package>

[rohit21agrawal]

@natemcmaster instead of making csproj + nuspec easier, i'd like to understand more about what we can do to make the need for nuspec go away.
what are some of the things that you can't achieve via csproj currently and for which you absolutely do need the nuspec?

[natemcmaster]

@rohit21agrawal

• Packing the output of multiple projects. Example: Microsoft.EntityFrameworkCore.Tools.nuspec
• "Fat packages". i.e. I want a nupkg with the output of "dotnet publish". Example: NuGetPackageVerifier.nuspec
• <summary>. cref Packing csproj with long description issues unresolvable warning about missing summary text NuGet/Home#4587.
• Explicitly defining the <dependencies> section.
  • Example: I want my MSBuild task package to say <dependencies><group targetFramework="Any"></group></dependencies>, but nuspec generation always uses <TargetFrameworks> which is set to the target frameworks for which the task assembly compiles. In this case, <TargetFrameworks> does not accurately represent which frameworks the package is compatible with.

[conniey]

I think this issue overlaps with: dotnet/msbuild#1756

[livarcocc]

Given that this conversation is happening around pack, I am moving this issue over to NuGet. Please, re-activate or file new issues for specific asks for the SDK to support this.

[livarcocc]

This issue was moved to NuGet/Home#5063