declaring nuget packages that depend on each other in one solution

Question

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.

I have two questions:

1. Is it possible to achieve this while keeping all projects within the same solution? If so how?
2. Is advisable to keep all projects in the same solution? What would be the a common / "best practice" approach to this?

Answer 1

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

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.

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.

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.)

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.

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.

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.