需要提供以下建议：
在我的公司，我正在开发供外部利益相关者使用的.NET类库，我正在利益相关者可以访问的私有NuGet源上共享它们。
库依赖于一个核心库，如下所示。目前我将这些库保存在单个VS解决方案中，显然是在一个Git仓库中。我跟随SemVer对它们进行了版本化。
CoreLibrary
CoreLibrary.Extension1 (references CoreLibrary as project reference)
CoreLibrary.Extension2 (references CoreLibrary as project reference)
...
There might be more of these extension libraries in the near future
到目前为止，我总是在Visual Studio中手动对它们进行版本化（每当我需要修改版本时手动在AssemblyInfo.cs中设置正确的值）并在每个项目中使用批处理文件来打包并推送该特定的库的NuGet。
但是现在我最近开始研究VSTS，我的下一个任务是尽可能自动化构建和发布，同时使用自动版本控制。我偶然发现了GitVersion，我认为这可以对最后一部分有所帮助。
但是，这里只是。如果我理解正确，GitVersion在存储库级别运行，因此由GitVersion计算的给定semver版本适用于存储库中的所有程序集/库，对吧？
那么您对这些库的发布和版本控制策略有何建议？
1）将所有内容保存在一个解决方案和repo中，每当需要发布的一个包（例如CoreLibrary.Extension1）发生更改时，这也会为所有其他库生成一个NuGet包。因此，如果所有软件包都在1.0.0上并且其中一个软件包中有一个小的更改，那么它们都会被压缩到v1.1.0并且所有软件包都被打包并推送？
2）为每个项目创建一个git repo，让GitVersion分别在每个repo上运行它的魔力。通过扩展库中的NuGet引用CoreLibrary。
选项2是我认为最干净的，并且具有每个项目处理版本控制和打包的优势，但在维护它们方面可能对工作负载来说太过分了，特别是考虑到我是这些工具的唯一开发人员。库。
你有什么想法？根据上下文，您会选择哪个选项？我是否错过了其他可能值得考虑的选择？
在自动构建和发布中设置我的第一步，所以任何建议都非常受欢迎。
由于
答案 0 :(得分：1)
您必须至少考虑以下两个因素：
当一个项目很小并且只有一个开发人员在这个项目上工作时，通常可以更容易地在一个存储库中完成工作并为所有版本剪切一个包。但是，即使对于单个开发人员来说，这也不能很好地适应库的数量。首先，VS在处理大型项目方面并不是特别擅长，但随着时间的推移，它在这方面确实会继续改进。即使这样，也存在实际限制，但单个开发人员不可能在不到几年的时间内达到该限制。
最终，即使是单一的开发人员，通常也希望能够在开发方面或支持客户方面取得成功，以满足规模需求。当一个重要客户发现extension1中的错误时，请考虑在您的extension2上进行一些主要工作的中途。现在你需要检查一个早期的提交，生成一个快速修复，剪切一个新包，测试，冲洗/重复，发布，返回你的回购头，樱桃挑选错误修复，然后继续。如果你一直在同一个仓库中的独立仓库甚至分支机构工作，那么任务就更容易组织，并且在第一次尝试时就能正确完成。
现在，我可以根据您的假设选择每个Nuget包需要单独的repo，或者GitVersion“在存储库级别运行”。通常，大多数文档和几乎所有的示例都可以满足单一产品/包/ repo格式，我可能会建议在大多数情况下，但实际上并不是一个硬性要求。 GitVersion在分支级别运行，如果没有不同的repo，你肯定应该为不同分支中的不同库进行开发。拥有一个主分支来合并所有东西，可能也是一个好主意，但Git或GitVersion不需要master。您可以在一个git仓库中拥有多个VS解决方案和项目，并且可以从中生成多个nuget包。我不是说你应该这样做，我说这不是一种不常见的做法，至少对于非平凡的产品线而言。
在客户方面，它实际上很大程度上取决于产品的性质。所有扩展都是必需的，甚至对每个客户都有用吗？你会为早期采用者制作alpha / beta版本吗？您的代码是否在服务器上使用？它是否用于移动设备？通常，您不希望在服务器上运行的任何代码都需要很长的升级时间，因此您应该认真考虑将产品线分解为多个独立版本的软件包。客户端过去在这方面并不那么重要，但在移动设备上，下载时间成为主要因素。并非每个人都拥有无限制的免费下载带宽，因此成本可能是一个主要因素。
如果您要生产大量的预发行版，您可能希望将产品线分解为单独的包。您仍然可以生成一个软件包包，但最终需要该选项，以便在模块级别发送更新。
一旦您进入一个repo / project / package / release-stream路径，您将快速开发出帮助维护它所需的自动化。这就像干净的编码实践，当你第一次开始时有点痛苦，但它最终成为第二天性，并且线下的回报可能是巨大的。请记住，没有任何理由说明为什么你不能拥有自己的解决方案和项目的多个repo，并且在父目录上有一个VS解决方案，它提供了一个完全集成的构建。只需将其视为构建系统的层次结构。您只需要学习如何使用.gitignore文件或git子模块（我更喜欢前者，因为后者的工具很弱）。
答案 1 :(得分：-2)
我强烈建议不要在这里使用任何nuget包。 Nuget旨在作为管理软件项目的第三方依赖关系的一种方式，而不是一种管理您定期构建的互连代码的方法。为此，您可以更好地拥有一个存储库，一个Visual Studio解决方案以及您构建/部署的单个构建堆栈。
如果你必须使用Nuget，只需用一个版本制作一个包。