如何在Git仓库中正确处理自有DLL依赖问题？

方案一：用NuGet私有源管理类库版本 #

这是多项目共享类库的最优解，核心是把类库打包成NuGet包通过私有源分发，GUI项目直接引用包而非源码或DLL：

• 给类库项目设置明确版本号（在.csproj里配置<Version>1.0.0</Version>）
• 执行dotnet pack命令打包类库，生成.nupkg文件
• 搭建私有NuGet源：可以是本地共享文件夹（适合小团队），或者内网NuGet服务器（比如用BaGet、NuGet.Server）
• 在GUI项目的NuGet包管理器中添加私有源，搜索并安装类库包
• 类库更新时，升级版本号重新打包发布，GUI项目直接更新包版本即可

这种方式下，克隆GUI项目后VS会自动还原NuGet包，无需手动处理DLL或类库源码，版本管理清晰，多个项目可灵活引用不同版本的类库。

方案二：Git子模块关联类库源码 #

如果需要在开发GUI时直接修改类库代码，用Git子模块把类库仓库嵌入GUI项目仓库：

• 在GUI项目根目录执行命令：

  git submodule add <类库仓库Git地址> lib/MyClassLib
  

• 提交子模块配置到GUI仓库，其他开发者克隆时用：

  git clone --recursive <GUI仓库地址>
  

  或者克隆后执行：

  git submodule init
  git submodule update
  

• 在GUI解决方案中添加对lib/MyClassLib下类库项目的引用（不是DLL），VS会自动编译类库并关联依赖

既能保持类库和GUI项目的仓库独立，又能在开发时直接编辑类库代码，提交时分别推送到各自仓库，GUI项目会记录当前依赖的类库版本。

方案三：Git子树合并类库代码 #

如果不想折腾子模块的复杂命令，用Git子树把类库代码合并到GUI仓库的指定目录：

• 在GUI项目中执行命令添加类库：

  git subtree add --prefix lib/MyClassLib <类库仓库地址> main
  

• 后续更新类库时，拉取最新代码合并：

  git subtree pull --prefix lib/MyClassLib <类库仓库地址> main
  

• 同样在GUI项目中引用类库的项目文件，自动编译依赖

这种方式相当于把类库代码嵌入GUI仓库，但保留类库的提交历史，克隆时直接拿到所有代码，无需额外操作，适合小团队或不想维护子模块的场景。

避坑提醒 #

绝对不要把编译生成的DLL提交到Git：DLL是编译产物，体积大、版本追踪困难，不同环境（比如不同VS版本、不同目标框架）编译的DLL可能存在兼容性问题，更新类库时还要手动替换DLL，极易出错。

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