声明在一个解决方案中相互依赖的nuget包

我们有很多项目的解决方案，这些项目之间有或多或少复杂的依赖关系图。现在，这些项目中的每一个都应该成为自己的nuget包，并且nuget包的依赖关系图应该反映项目的状态

我有两个问题：

在保持所有项目在同一个解决方案中的同时，是否可以实现这一点？如果是，怎么做

建议将所有项目保持在同一个解决方案中吗？对此，什么是通用/最佳实践方法

是的，你可以“很可能”做到这一点。我这么说可能是因为我还没有尝试过，但我会用这样的方式来处理：使用手动nuspec定义引用将起作用。如果你真的想变得更有趣，你可以写一些构建后的Roslyn代码来解析你的项目依赖关系并构建nuget依赖关系树。也就是说，不要这样做，在一个非平凡的解决方案中，它几乎肯定会很快变成手动的和脆弱的

---

最终，最好将您的解决方案分解——为每个Nuget包创建一个解决方案，并使用Nuget本身引入依赖项。假设您有一个build/CI服务器，这应该相当简单。只需运行您自己的Nuget repo，并在构建工件时发布它们——这样，您的依赖项目将获取您刚刚构建的最新包。您需要确保构建过程每次都刷新Nuget，并且可以使用标准的

Nuget spec

命令作为构建后步骤。作为一个不错的奖励，它将迫使所有从事代码工作的人在进行更改时真正考虑依赖关系。

我们项目中的情况是相同的，我们采取了以下方法：

第一步是创建定义包的nuspec文件。我们已将所有这些文件放置在名为“.nuspec”的文件夹中，该文件夹位于解决方案的根目录中。nuspec文件也添加到名为“.nuspec”的解决方案文件夹中的解决方案中

该解决方案本身有一个全局AssemblyInfo文件，其中包含版本控制信息以及一些版权信息——简言之，是我们项目之间常见的所有信息。然后，每个项目都有自己的程序集信息，并添加特定于每个项目的信息

nuspec文件不包含版本。相反，我们使用

$（版本）

作为占位符：

MyCompany.MyProduct.Server.DataAccess
$（版本）
我的公司
http://example.com/myProduct.html
http://example.com/myProduct.icon.png
假的
这里有一些描述。
总结如下
版权所有©MyCompany 2015
恩美

（当然，依赖项本身可能有依赖项。例如，服务器组件可能引用日志组件。）

最初，我们创建了一个控制台应用程序，从全局AssemblyInfo文件读取解决方案的版本，并在创建和发布包之前将其解析为所有nuspec文件

控制台应用程序工作得很好，但在启用了持续集成的TFS环境中进行维护有点繁琐。因此，我们定义了一个自定义TFS构建模板来完成这项工作。我们现在需要做的就是为所有项目创建一组nuget包，触发TFS构建

这种方法的优点是所有包都有相同的版本，因此可以很好地协同工作。 这种方法的缺点是所有包都有相同的版本，不能独立发布

---

我们之所以选择这种方法，是因为它阻止了我们生产一个由集成度差的组件组成的企业集团。我们的项目提供了一个小型框架，用于开发所有类似的小型LOB应用程序。由于我们在一组不同的包中交付框架，开发人员可以选择他们真正需要的包，然后只安装那些包。如果开发人员决定以后添加缺少的功能，他只需安装与已安装的软件包版本相同的相关软件包。因此，无需担心兼容性。

目前，在VS 2017中，您可以在一个解决方案中拥有多个库项目，这些项目构建在单独的包中，也可以通过

相互引用。令人惊讶的是，VS足够聪明，可以在构建解决方案时使用

，并为nuspec中的引用项目生成正确的包

。换句话说，您可以方便地在一个解决方案中同时处理多个项目，并将它们作为一组相互依赖的包发布。

回答得很好，谢谢。我们与您描述的情况完全相同，只是到目前为止，我们只构建了一个包含所有LIB的大型软件包。我们现在需要能够独立地引用不同的位，而不需要拉入所有其他不需要的cruft/web文件等。这正是您在最后几段中描述的内容-非常感谢。我得到的

“$（Version）”不是有效的版本字符串。

您在哪里定义它？@Wilbert请仔细阅读我的答案。我们最初使用一个小型控制台应用程序替换$（版本）占位符。现在我们使用TFS构建来实现这一目标。这很好，但它只在使用新的csproj格式时才起作用。也许你是对的，我很久没有使用旧格式了。嗯，我使用的是VS2017，但我从2015年导入了项目，并在每个项目中从命令行创建了.nuspec文件。现在只有两个项目，但是他们创建了两个包，它们之间没有依赖关系。有没有我可以使用的文档，或者你们知道怎么回事吗？@MichaelBlackburn我不是说命令行工具，我是说bu