如何兼顾NuGet包版本管理与子模块项目的联动开发？

方案1：条件式项目引用 + NuGet包引用（推荐） #

通过在消费项目的.csproj文件中添加条件判断，让开发环境直接引用本地子模块项目，发布/正式环境自动切换为NuGet包引用。这种方式无需额外工具，完全依赖MSBuild的条件逻辑。

具体配置 #

编辑消费项目的.csproj，替换原有的引用为以下内容：

<!-- 开发环境（Debug）：直接引用本地子模块项目 -->
<ProjectReference 
  Include="..\..\MySharedLibrary\MySharedLibrary.csproj" 
  Condition="'$(Configuration)' == 'Debug'" />

<!-- 正式/发布环境（Release）：引用NuGet包 -->
<PackageReference 
  Include="MySharedLibrary" 
  Version="1.0.*" 
  Condition="'$(Configuration)' != 'Debug'" />

如果需要更灵活的环境区分（比如区分本地开发和CI构建），可以自定义MSBuild属性：

<!-- 先定义自定义属性，可通过命令行或环境变量设置 -->
<PropertyGroup>
  <IsLocalDevelopment>true</IsLocalDevelopment>
</PropertyGroup>

<!-- 根据自定义属性切换引用 -->
<ProjectReference 
  Include="..\..\MySharedLibrary\MySharedLibrary.csproj" 
  Condition="'$(IsLocalDevelopment)' == 'true'" />

<PackageReference 
  Include="MySharedLibrary" 
  Version="1.0.*" 
  Condition="'$(IsLocalDevelopment)' != 'true'" />

优势 #

• 开发时直接修改子模块代码，实时同步到消费项目，无需打包安装。
• 发布/CI构建自动使用NuGet包，保证版本一致性。
• 无需额外工具，配置简单。

方案2：本地NuGet源 + 自动构建脚本 #

搭建本地NuGet源，配合自动化脚本实现子模块的快速打包推送，消费项目优先从本地源拉取包，既保留NuGet的版本管理优势，又能快速更新开发中的子模块。

步骤1：创建本地NuGet源 #

在本地创建一个文件夹作为本地源（比如C:\LocalNuGetFeed），然后在解决方案根目录的NuGet.config中添加该源：

<configuration>
  <packageSources>
    <add key="LocalFeed" value="C:\LocalNuGetFeed" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <!-- 设置本地源优先级高于nuget.org -->
  <packageSourceMapping>
    <packageSource key="LocalFeed">
      <package pattern="MySharedLibrary*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

步骤2：编写自动打包脚本 #

创建PowerShell脚本（Update-SharedLib.ps1），实现子模块的构建、打包和推送：

# 构建子模块项目
dotnet build ..\MySharedLibrary\MySharedLibrary.csproj -c Debug

# 打包并输出到本地NuGet源（使用预发布版本号，比如带-ci后缀）
dotnet pack ..\MySharedLibrary\MySharedLibrary.csproj -c Debug -o C:\LocalNuGetFeed -p:Version=1.0.0-ci-$((Get-Date).ToString("yyyyMMddHHmm"))

# 更新消费项目的NuGet包
dotnet add ..\MyConsumerApp\MyConsumerApp.csproj package MySharedLibrary --prerelease

开发时修改完子模块代码，直接运行脚本即可完成更新，消费项目会自动拉取最新的预发布包。

优势 #

• 保留NuGet的版本追踪能力，每个开发版本都有唯一标识。
• 自动化脚本减少手动操作，提升开发效率。
• 适合需要频繁测试子模块变更的场景。

方案3：Git Submodules + 项目引用映射 #

保留Git Submodules的代码隔离优势，同时在开发解决方案中直接添加子模块的项目文件作为现有引用，发布时切换为NuGet包引用，通过分支策略区分开发和发布状态。

具体操作 #

1. 将子模块克隆到解决方案的指定目录（比如src/Shared/MySharedLibrary）。
2. 在消费解决方案中，通过「添加现有项目」选择子模块目录下的.csproj文件，开发时直接修改子模块代码，提交到子模块仓库。
3. 在发布分支（比如release/*）中，将项目引用替换为NuGet包引用，确保发布版本使用正式包。

优势 #

• 子模块代码独立管理，不污染主解决方案仓库。
• 开发时联动修改，发布时保证版本稳定。
• 适合多团队协作、子模块被多个项目复用的场景。

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