Introduction

The message ''Newtonsoft.Json'' already has a dependency defined for ''Microsoft.CSharp'' usually points to NuGet package metadata generation, not to a runtime JSON bug. In other words, the package build process believes the same dependency has been declared twice for the same target framework group. The fix is usually to remove duplicate dependency declarations and let one packaging mechanism own the dependency metadata.

What the Error Actually Means

This kind of message typically appears when creating or packing a NuGet package. The package definition ends up describing Microsoft.CSharp more than once for Newtonsoft.Json or for a package that references it.

Common causes include:

• duplicate entries in a .nuspec,
• explicit dependency declarations plus auto-generated dependency metadata,
• multiple target framework groups that accidentally repeat the same dependency incorrectly,
• mixing legacy packages.config assumptions with SDK-style pack behavior.

The important point is that the package metadata is inconsistent before the package is published or consumed.

Example of a Duplicate Dependency Problem

A problematic .nuspec might look conceptually like this:

1<dependencies>
2  <group targetFramework=".NETFramework4.7.2">
3    <dependency id="Microsoft.CSharp" version="4.7.0" />
4    <dependency id="Newtonsoft.Json" version="13.0.3" />
5    <dependency id="Microsoft.CSharp" version="4.7.0" />
6  </group>
7</dependencies>

That package definition repeats the same dependency in the same group, which NuGet rejects.

Let SDK-Style Packing Infer Dependencies

In modern SDK-style .csproj projects, package dependencies are usually inferred automatically from PackageReference.

Example:

1<Project Sdk="Microsoft.NET.Sdk">
2  <PropertyGroup>
3    <TargetFramework>net8.0</TargetFramework>
4    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
5  </PropertyGroup>
6
7  <ItemGroup>
8    <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
9  </ItemGroup>
10</Project>

If you are already using this approach, avoid adding the same dependency again manually in a .nuspec unless you have a very specific packaging reason.

Avoid Mixing .nuspec and Auto-Inference Blindly

A common source of the error is combining:

• SDK-style PackageReference,
• 'dotnet pack or msbuild -t:pack,'
• and a custom .nuspec that also declares dependencies explicitly.

That can create duplicate dependency information because the project file and the nuspec both try to describe the same package graph.

A cleaner strategy is:

1. let the SDK infer dependencies from PackageReference, or
2. manage the dependency list explicitly in one place, but not both.

Check Target Framework Groups Carefully

For multi-targeted packages, the duplication may exist only inside one target framework group.

Example multi-target project:

<PropertyGroup>
  <TargetFrameworks>net472;net8.0</TargetFrameworks>
</PropertyGroup>

If you customize dependency groups manually, verify that Microsoft.CSharp is not being injected twice for the same target framework while appearing once for another. The error message is often about one specific group, even if the package is otherwise valid.

How to Debug the Packaging Metadata

Useful checks:

• inspect the .nuspec file generated in the package output,
• search for repeated Microsoft.CSharp entries,
• review custom pack targets,
• remove temporary manual dependency overrides and pack again.

If the project is SDK-style, start by simplifying rather than adding more metadata. Packaging problems usually get easier when there is only one source of truth.

Practical Fixes

Depending on the project style, the fix is usually one of these:

• remove the duplicate dependency line from the .nuspec,
• stop manually declaring Microsoft.CSharp if PackageReference already captures it,
• consolidate dependency generation into the SDK pack flow,
• clean old packaging artifacts and repack after simplifying metadata.

If Newtonsoft.Json itself is the dependency, you rarely need to manually restate transitive dependencies unless you are building a very custom package layout.

Common Pitfalls

• Treating the message as a runtime Json.NET error when it is really a NuGet packaging metadata problem.
• Defining the same dependency manually in a .nuspec while also relying on SDK-style automatic dependency inference.
• Debugging the consuming application before checking the generated package metadata itself.
• Over-customizing target framework dependency groups without verifying duplicates per group.
• Keeping legacy packaging files in a modern SDK-style project when the project file alone would be simpler and safer.

Summary

• The error usually means the package metadata defines Microsoft.CSharp more than once.
• The most common cause is duplicate dependency declaration during NuGet packing.
• In SDK-style projects, let PackageReference drive dependency inference unless you have a strong reason not to.
• Check generated .nuspec output and target framework groups for repeated entries.
• Simplifying the packaging path is usually the fastest fix.