用 dotnet pack 打包类库最直接
只要项目是 SDK 风格(
.csproj文件里有
<sdk>Microsoft.NET.Sdk</sdk>),不用额外装工具,直接命令行运行:
dotnet pack --configuration Release就会在
bin/Release下生成
.nupkg文件。注意别漏掉
--configuration Release——Debug 模式打包可能含调试符号、版本号带
-dev后缀,上传到 NuGet.org 会被拒。
常见错误:项目没设
<packageid></packageid>和
<version></version>,打包后文件名是
Unnamed.1.0.0.nupkg。必须在
.csproj里显式写:
<PropertyGroup> <PackageId>MyAwesomeLib</PackageId> <Version>1.0.0</Version> <Authors>YourName</Authors> <Description>A short description</Description> </PropertyGroup>
nuget.exe push 发布到 nuget.org
发布前先去 nuget.org 创建 API Key(只显示一次,务必复制保存)。然后执行:
nuget.exe push MyAwesomeLib.1.0.0.nupkg -Source https://api.nuget.org/v3/index.json -ApiKey YOUR_API_KEY_HERE如果提示
nuget.exe找不到,就去 下载最新版 并加到 PATH,或者用完整路径调用。
容易踩的坑:
API Key 权限范围要选 “Push new packages”(不是 “All packages”) 包名已存在且你不是所有者?会报错403 Forbidden版本号重复?报错
409 Conflict,得升版再推
用 Directory.Build.props 统一管理多项目元数据
如果你维护多个类库,每个都手写
PackageId、
Description容易不一致。可以在解决方案根目录建
Directory.Build.props,内容如下:
<Project>
<PropertyGroup>
<PackageProjectUrl>https://github.com/you/repo</PackageProjectUrl>
<RepositoryUrl>https://github.com/you/repo</RepositoryUrl>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<IncludeSymbols>false</IncludeSymbols>
</PropertyGroup>
</Project>所有子项目的 .csproj就能自动继承这些设置,不用每处重复写。
注意:
IncludeSymbols默认为
true时会生成
.snupkg,但 nuget.org 要求它和
.nupkg版本严格一致;若不打算提供源码调试支持,显式关掉更省事。
本地测试包是否可用,别跳过这步
上传前,先在本地验证包结构和引用是否正常:
用nuget.exe install MyAwesomeLib.1.0.0.nupkg -OutputDirectory ./test解压看看
lib/目录下有没有对应框架的 dll(比如
net6.0/或
netstandard2.0/) 新建一个测试项目,执行
dotnet add package MyAwesomeLib --source ./test,看能否成功解析并编译通过 检查
.nuspec内容(用
nuget.exe spec生成模板对比):
<dependencies></dependencies>是否漏了
<group targetframework="net6.0"></group>这类声明 很多“上传成功但别人引用失败”的问题,其实是因为
TargetFrameworks和
PackageReference的兼容性没对齐,本地测一遍能避开 80% 的尴尬。
真正麻烦的是跨平台目标框架(比如同时支持
net6.0和
netstandard2.0)+ 带原生依赖的场景,这时候
lib/下目录结构、
runtimes/分组、
.targets文件都要手动校验——别指望
dotnet pack全替你兜底。
