CODEWITHSUNDEEP
c#.netdependenciesnugetnuget-package
Charles Ouellet
Charles Ouellet

Reputation: 6518

Create nuget package for a solution with multiple projects

We are currently building a solution with several projects.

We have something like this:

- Common
  - Logging
     - Logging.NLog
- Threading

So Logging.NLog is dependant on Logging, Logging on Common...etc.

When we pack Logging.NLog I would like nuget to discover the Loggin and Common dependecies.

At the moment, I created a package with Common, then in Logging I installed the package Common with

install-package Common

But whenever I do a modification to Common, I have to update the package and they are created by our continous integration systeme (Hudson), so it is pretty annoying when we are developing.

I would like to simply have a Project Reference (Add References -> Project...) and the nuget discover the depencies anyway.

Is there a way to achieve it?

Upvotes: 25

Views: 35384

Answers (5)

Silny ToJa
Silny ToJa

Reputation: 2261

I managed this achieve it like this:

<ProjectReference Include="MyProject2.csproj" PrivateAssets="All" />

Add PrivateAssets="All" in MyProject.csproj for each project.

Upvotes: 0

Cristian Diaconescu
Cristian Diaconescu

Reputation: 35621

There is a planned feature targeting this exact scenario.

This is how it will apparently look like:

> nuget.exe pack proj.csproj -IncludeReferencedProjects

It has apparently been implemented mere days ago, but there are bugs still being ironed out.

The feature, as it currently stands, allows:

  • packaging several projects' artifacts into a single nuget package (by walking project references recursively),

OR

  • creating nuget package references to those projects's associated packages, if the referenced projects have accompanying .nuspec files.

The feature request dates back all the way to 1.5, but it kept slipping. Recently though, it gathered enough mass (requests) to be scheduled for release in Nuget 2.3.

The release plan pegs version 2.3 for "End of April, 2013" so stay tuned.
(Presently, the latest Nuget version is 2.2.1).

Upvotes: 22

Daniel Dyson
Daniel Dyson

Reputation: 13230

There is currently no way to do exactly what you ask, but the following will help you streamline your updates.

It sounds like you need to add nuspec files to your solution. Something like the following three files. Note the dependencies in the second two. These refer to the same dll version as common through [$version$]. This means that when you run the following command, it updates all three because the square brackets on the dependencies require a specific version of the dependent packages.

PM> update-package common

In Hudson, you will need to execute these nuspec files using nuget pack command (see Nuget command reference) and include the resulting packages in your artifacts, AND deploy them to your local nuget server. I will leave that over to you.

The other thing you would need to do is ensure that all of your assemblies get the same version for the same build. Again, Hudson can take care of this or you could use a common AssemblyInfo file.

Common.nuspec

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
    <version>$version$</version>
    <authors>Charles Ouellet</authors>
    <owners />
    <iconUrl>http://domain/Content/images/LOGO_32x32.png</iconUrl>
    <id>Common</id>
    <title>Common</title>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>full description here</description>
</metadata>
<files>
    <file src="..\Common\bin\Release\Common.dll" target="lib\net40" />
    <file src="..\Common\bin\Release\Common.pdb" target="lib\net40" />
</files>
</package>

Logging.nuspec

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
    <version>$version$</version>
    <authors>Charles Ouellet</authors>
    <owners />
    <iconUrl>http://domain/Content/images/LOGO_32x32.png</iconUrl>
    <id>Logging</id>
    <title>Logging</title>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>full description here</description>
    <dependencies>
        <dependency id="Common" version="[$version$]" />
    </dependencies>        
</metadata>
<files>
    <file src="..\Logging\bin\Release\Logging.dll" target="lib\net40" />
    <file src="..\Logging\bin\Release\Logging.pdb" target="lib\net40" />
</files>
</package>

Logging.NLog

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
    <version>$version$</version>
    <authors>Charles Ouellet</authors>
    <owners />
    <iconUrl>http://domain/Content/images/LOGO_32x32.png</iconUrl>
    <id>Logging.NLog</id>
    <title>Logging.NLog</title>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>full description here</description>
    <dependencies>
        <dependency id="Logging" version="[$version$]" />
    </dependencies>        
</metadata>
<files>
    <file src="..\Logging.NLog\bin\Release\Logging.NLog.dll" target="lib\net40" />
    <file src="..\Logging.NLog\bin\Release\Logging.NLog.pdb" target="lib\net40" />
</files>
</package>

Upvotes: 3

Matthew Skelton
Matthew Skelton

Reputation: 2220

This thread has a good suggestion: NuGet and multiple solutions

Basically, break out the common components to their own Solution, with their own release lifecycle.

Upvotes: 1

R. Otten
R. Otten

Reputation: 41

I think Charles means he wants NuGet to automatically resolve project references into package dependencies if said referenced projects also are used to construct NuGet packages, right?

Example:

  1. Logging is set up to generate a NuGet package
  2. Logging.Nlog is set up to generate a NuGet package
  3. Logging.Nlog has a project reference to Logging.
  4. The generated Logging.Nlog package should get a dependency on the generated Logging package.

This is something I had been looking for myself as well, but sadly I found that it is currently not supported. There is a work item on it, scheduled for NuGet 1.7, but there isn't even a design on how to handle this yet.

Upvotes: 2

Related Questions