在C#开发中，NuGet包已经成为复用代码、共享组件以及管理第三方库的标准方式。无论是企业内部的基础设施团队，还是开源社区的个人开发者，都可以通过创建和发布NuGet包，把通用功能封装成稳定的可分发单元。本文将以一个简单的字符串工具类库为例，完整说明从创建项目、配置元数据、生成包文件到发布仓库以及被其他项目引用的过程。
一、创建适合NuGet打包的类库项目
NuGet包的核心内容通常来自一个类库项目，因此创建正确的项目类型是打包的第一步。在Visual Studio中新建项目时，可以选择“类库(.NET Standard)”或者“类库(.NET)”。如果希望包能够同时被.NET Framework和.NET Core/5+等不同运行时引用，建议优先选择.NET Standard作为目标框架；如果只需要服务于特定的.NET版本，也可以直接选择对应的.NET类库模板。这里以.NET Standard 2.0为例，它具备较广的兼容范围，适合作为基础工具库的目标平台。
项目名称可以自定义，例如命名为MyUtils。创建完成后，在项目中添加一个简单的静态工具类，用来验证后续打包和引用流程是否正常。即使工具类的方法非常简单，也不会影响对整个NuGet发布流程的理解，反而能够让我们把注意力集中在打包元数据和发布命令上。
using System;
namespace MyUtils
{
public class StringHelper
{
/// <summary>
/// 判断字符串是否为空或空白
/// </summary>
/// <param name="input">输入字符串</param>
/// <returns>是否为空或空白</returns>
public static bool IsNullOrWhiteSpace(string input)
{
return string.IsNullOrWhiteSpace(input);
}
}
}
上面的StringHelper包含一个判断字符串是否为空或空白的方法，它直接委托给string.IsNullOrWhiteSpace。对于真实项目，开发者可以替换为更复杂的业务逻辑，但核心打包流程完全一致。
二、在项目文件中配置NuGet元数据信息
光有类库代码还不够，NuGet包对外展示时需要明确的身份信息。这些信息通常写在项目文件（.csproj）的<PropertyGroup>节点中。右键点击项目并选择编辑项目文件，可以直接打开XML格式的配置内容。需要添加的元数据包括包的唯一标识、版本号、作者、公司、描述、标签以及许可证表达式等。
包标识PackageId是其他项目安装时使用的名称，它不应随意变更；Version遵循语义化版本规范，每次发布新包时都需要递增。描述和标签则帮助使用者在包管理器中快速了解包的功能。许可证表达式使用SPDX标识，例如MIT，可以明确使用条件。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<!-- 包的基本信息 -->
<PackageId>MyUtils.Core</PackageId>
<Version>1.0.0</Version>
<Authors>TestAuthor</Authors>
<Company>TestCompany</Company>
<Description>通用字符串处理工具类库</Description>
<PackageTags>C#,工具,字符串处理</PackageTags>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<GeneratePackageOnBuild>false</GeneratePackageOnBuild>
</PropertyGroup>
</Project>
上面的配置中，GeneratePackageOnBuild设置为false，表示不在每次生成项目时自动打包，而是使用后续的命令手动触发。这样做的好处是，可以在发布前精确控制打包时机，避免生成大量不必要的中间包文件。对于需要持续集成的场景，也可以将其设置为true，让每次构建都自动产出包。
三、使用dotnet pack生成本地NuGet包
完成项目文件和代码准备后，就可以生成NuGet包。生成操作不依赖Visual Studio的图形界面，使用.NET CLI命令更加直接和可重复。打开终端，将当前目录切换到项目所在位置，然后执行打包命令。
dotnet pack -c Release
执行成功后，命令行会输出生成的包路径。通常该文件位于项目的bin/Release目录下，扩展名为.nupkg。这个文件实际上是一个ZIP压缩包，内部包含编译后的DLL、依赖关系描述以及元数据文件。可以使用NuGet Package Explorer等工具打开它，检查目录结构、目标框架和依赖信息是否符合预期。
如果打包失败，常见原因包括元数据不完整、目标框架不受支持或者项目中存在语法错误。检查终端输出的错误信息，通常可以快速定位问题。确认包内容无误后，就可以进入发布环节。
四、发布NuGet包到目标仓库
生成的本地包并不能被其他开发者直接安装，除非他们手动添加本地源。要实现团队协作或公共分发，需要将包推送到NuGet仓库。最常用的目标仓库是NuGet官方仓库，企业也可以搭建私有NuGet仓库作为内部源。
发布到官方仓库前，需要先注册账号并获取API Key。API Key是推送包时的身份凭证，应当妥善保管，不要写入版本控制或共享给无关人员。推送命令如下：
dotnet nuget push bin/Release/MyUtils.Core.1.0.0.nupkg --api-key 你的API_Key --source https://api.nuget.org/v3/index.json
执行后，命令行会显示发布进度。如果网络稳定，通常很快完成。发布成功后，需要等待一段时间让索引生效，之后其他项目就可以通过NuGet包管理器搜索到该包。私有仓库的发布方式类似，只需要把--source参数后面的地址替换为内部仓库地址即可。
五、管理包版本与依赖关系
版本管理是NuGet包维护中的关键环节。建议严格遵循语义化版本规范，格式为主版本号.次版本号.修订号（MAJOR.MINOR.PATCH），例如 1.0.0 表示主版本号 1、次版本号 0、修订号 0。主版本号在出现不兼容 API 变更时递增，次版本号在向后兼容地添加功能时递增，修订号在向后兼容地修复缺陷时递增。如果包还处于预发布阶段，可以在版本号后追加连字符和标识符，如 1.0.0-beta.1。NuGet 支持语义化版本并做了一些扩展，但对外发布时建议严格使用三位版本号，避免生态工具解析异常。 依赖关系应通过项目文件中的 PackageReference 声明。为避免意外升级引入破坏性变更，建议为依赖项指定明确的版本范围。例如：
<PackageReference Include="Newtonsoft.Json" Version="[13.0.0,14.0.0)" />方括号表示包含该版本，圆括号表示不包含该版本。也可以使用通配符版本，例如：
Version="13.*"但发布包时不要使用通配符版本，这样会降低构建的可重复性。更稳妥的做法是锁定最小可用版本，并定期手动升级依赖。 更新包时，修改项目文件中的 Version 属性，然后重新执行 dotnet pack，生成新的 .nupkg 文件。不能只修改版本号而不重新打包。推送到仓库后，下游项目可以使用 dotnet add package 或更新包命令获取新版本。如果变更包含破坏性 API 调整，必须递增主版本号，并在包的描述或发行说明中明确提示迁移成本。
六、在项目中消费 NuGet 包
在其他项目中安装包，最直接的方式是使用 dotnet add package 命令：dotnet add package MyUtils.Core --version 1.0.0执行后，项目文件会自动加入 PackageReference，并执行包还原。也可以手动编辑 csproj 文件，添加 PackageReference 后运行 dotnet restore。使用第三方包时要注意传递依赖冲突。如果出现 NU1605、NU1107 等错误，通常意味着依赖版本不一致或存在降级，需要检查完整依赖树，必要时在项目中显式添加更高版本的 PackageReference 进行统一。