Add SuppressDependenciesWhenPacking to MSBuild package#30
Merged
Conversation
Microsoft.Build.Framework and Microsoft.Build.Utilities.Core were declared with ExcludeAssets="runtime" only, which prevents the DLLs from being copied to the build output but does NOT suppress them from the packed .nuspec. As a result, every consumer of DemaConsulting.ApiMark.MSBuild received these as transitive NuGet dependencies, pulling in unintended transitive packages such as System.Memory 4.6.3. Since the MSBuild host provides these assemblies at runtime, they have no business appearing in consumers' NuGet graphs. Adding PrivateAssets="all" suppresses them from the .nuspec entirely, matching the existing treatment of SourceLink.GitHub and Polyfill. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adjusts MSBuild-related PackageReference metadata in ApiMark.MSBuild.csproj so MSBuild assemblies remain compile-time only and are not flowed as transitive NuGet dependencies when packing the MSBuild integration package.
Changes:
- Added
PrivateAssets="all"toMicrosoft.Build.FrameworkandMicrosoft.Build.Utilities.Corepackage references to suppress transitive dependency propagation during packing.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ependenciesWhenPacking ApiMark.MSBuild is a build-plugin package, not a library. The MSBuild host provides Microsoft.Build.* at runtime, and ApiMark.Tool with its dependencies is bundled directly in the package under tools/. No NuGet dependency should ever propagate to a consumer's dependency graph. Replace the per-reference PrivateAssets approach with the project-level SuppressDependenciesWhenPacking=true property, which encodes this architectural intent directly and guards against future references inadvertently leaking into consumers' NuGet graphs. Document the rationale in the MSBuild design doc under Dependencies and Design Constraints. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Malcolmnixon
changed the title
This was referenced Jun 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request updates the MSBuild integration for the ApiMark tool, clarifying how dependencies are handled and ensuring that no unnecessary NuGet dependencies propagate to consumers. The changes document and enforce that the package acts as a build plugin, not a traditional library, and that all required tooling is bundled directly.
Dependency handling and packaging improvements:
Microsoft.Build.*dependencies are declared withExcludeAssets="runtime", ensuring they are only used for compilation and not included in the build output, as the MSBuild host provides them at runtime.SuppressDependenciesWhenPacking=trueto the project file and documented it, guaranteeing that no NuGet dependencies from this package will flow into consumers' dependency graphs, since all necessary tools are bundled directly. [1] [2]