我有一个完整的项目解决方案，这些项目将作为通用nuget软件包在我的组织之间共享。该解决方案包含在一个git存储库中，并且让TeamCity为我们运行构建，尽管我们并不过分先进，因为在准备为以下项目中的给定项目生成/发布新的Nuget包时，我们会手动启动Teamcity构建。解决方案中，每个项目都有自己的TeamCity构建配置。
在构建时，项目通过.csproj <project/>标签生成nuget包：GeneratePackageOnBuild我们还通过version标签控制版本控制，这些标签是通过TeamCity的构建属性填充的。这很好。我们遇到问题的地方是管理项目对自身的项目引用/依赖性。我似乎无法理解如何正确执行此操作。例如：
-- Solution
----- Project A v1.0.6
----- Project B v1.0.1
项目A（v1.0.6）对项目B（v1.0.1）有依赖性。假设我同时更改了Project A（v1.0.7）和Project B（v1.0.2）。我无法让Project A引用Project B的nuget包，因为它尚未构建，因此我使用Project References。但是，这会使Package A（v1.0.7）的nuget软件包假定它具有与Project B（v1.0.2）相同的内部版本号，但没有。因此，当某人使用Project A时，他们被告知寻找不存在的依赖项Project B版本（在示例中为v1.0.7）。为解决此问题，我在项目A .csproj中添加了以下内容：
<ProjectReference Include="..\Company.ProjectB\Company.ProjectB.csproj" ExcludeAssets="All" />
但是，现在消费者不知道Project B依赖项（因为它不再显示在Nuget包依赖项中），当他们发现需要它时，在使用Project A时会遇到运行时错误指出它仍在寻找显然不存在的Project B v1.0.7。
在生成没有nuspec的nuget包时，如何智能地处理项目引用？我希望尽量减少人工干预。
我的另一个解决方案是使用Nuget包引用，但这意味着项目B必须先构建和部署，然后开发人员才能进行项目A的工作。
答案 0 :(得分：1)
根据设计，当打包具有项目引用的项目时，那些从属项目将作为NuGet依赖项添加，最低版本是打包时每个项目的当前版本。要理解为什么，想象一下您对ProjectB进行了重大更改，并修复了ProjectA使其可以使用。如果发布ProjectA，但具有旧版本ProjectB的NuGet依赖关系，则ProjectA的NuGet用户将在运行时崩溃，因为他们使用的ProjectB版本不兼容。 NuGet无法知道这一点。
因此，如果要增加ProjectA的版本而不增加ProjectB的依赖版本，请将它们分开提交。否则，请同时发布ProjectA和ProjectB的新版本。