这是个很常见的.NET类库依赖问题，我来帮你拆解原因和可行的修复方案：

为什么类库的依赖没体现在生成的DLL里？ #

.NET类库项目默认的行为是只编译自身代码到DLL中，不会将依赖的NuGet包嵌入或打包到输出DLL里。这是NuGet依赖管理机制的设计初衷：

• NuGet的核心是共享依赖、避免重复打包相同库，同时保证依赖版本的一致性
• 类库只是声明自己需要哪些依赖，当其他项目引用你的类库时，NuGet会负责解析并获取这些依赖——但前提是你的类库是以NuGet包的形式被引用，而非直接引用输出的DLL文件

你直接引用/bin/debug里的DLL时，消费项目无法感知这个DLL依赖了哪些NuGet包，自然不会自动下载这些依赖，所以运行时会报错找不到程序集。

可行的修复方案 #

方案1：将类库打包为NuGet包（推荐，最符合.NET生态的干净方案） #

这是.NET类库分发的标准方式，能自动传递依赖：

• 确保你的类库项目文件（.csproj）里已正确添加两个NuGet包的PackageReference：

  <PackageReference Include="Microsoft.Win32.Registry" Version="4.6.0" />
  <PackageReference Include="System.Data.SqlClient" Version="4.7.0" />
  

• 在类库项目目录下运行命令生成NuGet包：

  dotnet pack --configuration Release
  

  生成的.nupkg文件会在/bin/Release目录下
• 在消费项目中，通过NuGet包管理器安装你自己的类库包——此时NuGet会自动检测并安装Microsoft.Win32.Registry和System.Data.SqlClient这两个依赖，无需手动添加

方案2：将依赖嵌入到类库DLL中（适合需要分发单个DLL的场景） #

如果你必须只给消费项目提供一个DLL，可以用工具将依赖嵌入：

• 安装Costura.Fody NuGet包到你的类库项目：

  Install-Package Costura.Fody
  

• 重新构建类库，Costura会自动把依赖的两个DLL嵌入到你的类库DLL中，运行时会自动从嵌入资源中提取并加载这些依赖
• 注意：这种方式要确认依赖库的许可证允许嵌入分发，同时如果消费项目本身也引用了这些依赖的不同版本，可能会出现版本冲突问题

方案3：使用项目引用（适合同一解决方案内的场景） #

如果消费项目和你的类库项目在同一个解决方案里：

• 直接在消费项目中添加项目引用（而非引用DLL文件）
• Visual Studio会自动处理依赖关系，构建时会把类库和它的依赖DLL一起复制到消费项目的输出目录，运行时就不会报错

总结 #

优先推荐方案1，这是.NET生态中依赖管理的标准做法，能保持依赖关系的清晰和可维护性。方案2适合需要单文件分发的场景，但要注意潜在的版本冲突和许可证问题。

内容的提问来源于stack exchange，提问作者EhSan