How to make the capabilities of this nuget package take effect globally in my CI process

[ymstar]

Hey @teneko . I have another question I'd like to ask you.

Our team has a unified CI process for building all dotnet projects within the company.

Instead of having every project in each team install this nuget package, I want to integrate it into the CI process so that it takes effect automatically for all projects. Are there any good methods?

I know that MSbuild supports globally customized Tasks or Targets, but in your project, the two Targets under build/xxx and buildMultiTargeting/xxx confuse me, and I don't know how to use them.

Additionally, I am in China. All these contents were translated by AI. If there are any inaccuracies, please forgive me.

Thanks.

[teneko]

Hi @ymstar,

Your question is clear, and the AI translation is good enough, so no problem.

Short answer: yes, you can apply this package centrally in CI, but not completely automatically unless you provide some shared MSBuild import.

This package works through the standard NuGet build/ and buildMultiTargeting/ folders. In normal usage, you do not call those files manually. NuGet imports them automatically when a project references this package and restores it. The buildMultiTargeting/ folder is mainly relevant for the outer build of SDK-style projects that use TargetFrameworks. In this package, it just forwards to the same logic from build/, so in practice you usually do not need to treat them differently.

The cleanest approach is to put the PackageReference into a shared Directory.Build.props file, or into a company-wide SDK, so projects in your CI process get this package automatically. Then, in the actual project files, you still use PrivateAssets="all" on the specific ProjectReference items whose build output should be copied into the .nupkg.

For example, a shared Directory.Build.props could look like this:

<Project>
  <ItemGroup>
    <PackageReference Include="Tenekon.MSBuild.Packaging.ProjectBuildInPackage" Version="2.0.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>
</Project>

And a project that wants to embed the output of another project would still do this:

<ItemGroup>
  <ProjectReference Include="..\MyLibrary\MyLibrary.csproj"
                    PrivateAssets="all" />
</ItemGroup>

That part is important because this package intentionally looks for ProjectReference items with PrivateAssets="all". That metadata is the signal telling the target which referenced project outputs should be copied into the NuGet package. So even if the package itself is added centrally, there still needs to be some opt-in rule for the referenced projects you want to embed.

There is also an optional mechanism if you want more explicit control from central MSBuild logic. NuGet supports GeneratePathProperty="true" on PackageReference. This generates an MSBuild property pointing to the restored package path. For this package, that property will be similar to $(PkgTenekon_MSBuild_Packaging_ProjectBuildInPackage).

If you use that approach to import the package's .props or .targets files explicitly, then you should not consume the automatic build assets at the same time. In other words, you would normally leave out build, buildMultitargeting, and buildTransitive from IncludeAssets for that reference, and then import the files you want explicitly from the generated package path.

For example:

<Project>
  <ItemGroup>
    <PackageReference Include="Tenekon.MSBuild.Packaging.ProjectBuildInPackage" Version="2.0.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; native; contentfiles; analyzers</IncludeAssets>
      <GeneratePathProperty>true</GeneratePathProperty>
    </PackageReference>
  </ItemGroup>

  <Import Project="$(PkgTenekon_MSBuild_Packaging_ProjectBuildInPackage)\build\Tenekon.MSBuild.Packaging.ProjectBuildInPackage.props"
          Condition="Exists('$(PkgTenekon_MSBuild_Packaging_ProjectBuildInPackage)\build\Tenekon.MSBuild.Packaging.ProjectBuildInPackage.props')" />
</Project>

In practice, this is optional, because a normal PackageReference already imports the package's .props and .targets automatically. It is mainly useful if you want to reference the package files explicitly from your own central MSBuild setup.

If you want to do this only in CI, you can generate or import a shared Directory.Build.props before dotnet restore and dotnet pack. That works, but it is usually a bit more fragile than committing a shared MSBuild file into the repository or using a shared SDK.

So the practical answer is:

• Yes, central CI integration is possible.
• The cleanest approach is a shared Directory.Build.props or shared SDK.
• build/ and buildMultiTargeting/ are normal NuGet/MSBuild import locations, not something you usually invoke directly.
• If you want explicit control, GeneratePathProperty="true" can help you reference the package files from your own shared MSBuild logic.

[ymstar]

[teneko]

Did you copy my comment, and perhaps everything else as well, @ymstar? 🙂

Please, I ask nothing more than that you credit me:

Copyright (c) 2024 Tenekon. Licensed under the MIT License.

You are free to make any changes you wish; just add your own credit below it as well, if you want to include yourself.