在一个解决方案中声明相互依赖的nuget包 [英] declaring nuget packages that depend on each other in one solution

问题描述

我们为许多项目提供了解决方案，并且这些项目之间的依赖关系图或多或少地复杂.现在，这些项目中的每一个都应成为自己的nuget程序包，并且nuget程序包的依赖关系图应反映项目的状态.

We have solution with a lot of projects and a more or less complex dependency graph between those projects. Now each of those projects should become its own nuget package and the dependency graph of the nuget packages should mirror the on of the projects.

我有两个问题:

1. 是否可以在将所有项目都放在同一解决方案中的同时实现这一目标?如果可以，怎么办?
2. 是否建议将所有项目保持在同一解决方案中?常见的最佳实践"方法是什么?

推荐答案

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

The situation in our project is the same and we took the following approach:

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

The first step is to create the nuspec files defining your packages. We have placed all theses files in a folder named ".nuspec" which is located in the solution's root directory. The nuspec files are added to the solution in a solution folder that is named ".nuspec", too.

该解决方案本身具有一个全局AssemblyInfo文件，其中包含版本信息以及一些版权资料-简而言之，是我们项目之间通用的所有信息.然后，每个项目都有自己的装配信息，并添加每个项目的特定信息.

The solution itself has a global AssemblyInfo file that contains the versioning information as well as some copyright stuff - in short all information that is common between our projects. Each project then has its own assembly info adding the information specific to each project.

nuspec文件不包含版本.相反，我们在其中使用$(version)作为占位符:

The nuspec files do not contain a version. Instead we use $(version) as a placeholder there:

<?xml version="1.0" encoding="utf-16"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
  <metadata>
    <id>MyCompany.MyProduct.Server.DataAccess</id>
    <version>$(Version)</version>
    <authors>MyCompany</authors>
    <projectUrl>http://example.com/myProduct.html</projectUrl>
    <iconUrl>http://example.com/myProduct.icon.png</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Some description goes here.</description>
    <summary>The summary goes here</summary>
    <copyright>Copyright © MyCompany 2015</copyright>
    <language>en-US</language>
    <dependencies>
      <dependency id="MyCompany.MyProduct.Common" version="$(Version)" />
      <dependency id="MyCompany.MyProduct.Server" version="$(Version)" />
    </dependencies>
  </metadata>
  <files>
    <file src="path\to\MyCompany.MyProduct.Server.DataAccess.dll" target="lib\net45\MyCompany.MyProduct.Server.DataAccess.dll" />
  </files>
</package>

(当然，依赖项本身可能也具有依赖项.例如，服务器组件可能引用日志记录组件.)

(Of course the dependencies might have dependencies themselves. The server component might reference a logging component for example.)

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

Initially we created a console application reading the version of the solution from the global AssemblyInfo file and parsing it into all of the nuspec files before creating and publishing the packages.

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

The console application worked well, but was a bit tedious to maintain in a TFS environment with continuous integration enabled. So we defined a custom TFS build template doing this work. All we need to do now to create a set of nuget packages for all of our projects is to trigger a TFS build.

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

This approach has the advantage that all packages have the same version and thus work well together. This approach has the disadvantage that all packages have the same version and cannot be released independently.

我们之所以选择这种方法，是因为它阻止了我们生产集成不良的组件.我们的项目提供了一个小型框架，用于开发所有非常相似的小型LOB应用程序.由于我们以一组不同的软件包交付框架，因此开发人员可以选择他们实际需要的软件包，然后仅安装它们.如果开发人员以后决定添加缺少的功能，那么他只会安装与已经安装的版本具有相同版本的相关软件包.因此，无需担心兼容性.

We chose that approach because it prevented us from producing a conglomerate of badly integrated components. Our projects provide a small framework that is used to develop small LOB-applications that all are quite similar. Due to the fact that we deliver the framework in a set of different packages the developers can choose which of the packages they actually need and then install only those. Should a developer decide to add a missing functionality lateron he just installs the relevant packages that have the same version as those already installed. Thus there's no need to worry about compatibility.

这篇关于在一个解决方案中声明相互依赖的nuget包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！