Creating NuGet packages from a solution

Alternate title: Packaging multiple projects into one NuGet package

[Updated Thursday, March 13th, 2014: Added Troubleshooting]


Background

For a recent client project, to make it easier for my developers to create certain types of projects, I created specialized NuGet packages that contained the most commonly referenced infrastructure pieces that they would need. For example, if they were to create a portable Application Service component, they would want to reference the shared Foundation library, followed by a Application Services Foundation library and some Common Data Types. I also knew that they would be dependent on a number of NuGet packages, prominently the Microsoft.Bcl package (which, in turn, references Microsoft.Bcl.Build).

Let's walk through how this is done!

To create a singular NuGet package containing all these references, create a new, Blank Visual Studio solution, add a Solution Folder called "Package Source" and a Portable Class Library Project (for packages targeting PCL):


In the Package Source, add the projects that you want included in this package. After adding the project, reference them from the PCL you created.

Add a .nuspec file to the project (I usually rename a text file):


The .nuspec file can read a lot of its properties from the source project. As a quick reminder, the assembly level attributes are, by default, located in the Properties\AssemblyInfo file.

If you need to reference any NuGet packages, just right-click the project and click Manage NuGet Packages as usual.

The Post-Build Step

nuget pack "$(ProjectPath)" -IncludeReferencedProjects -OutputDir "$(SolutionDir)..\..\Packages"

Given all of the configuration ceremony above, to create a NuGet package from our project, we invoke NuGet Pack, passing in the full path to our project. Since we have a .nuspec-file with the same name as our project in the project directory, NuGet will pick up the .nuspec file and configure the package accordingly. The flag IncludeReferencedProjects ensures that the projects referenced by our PCL are included in the package. If these projects have .nuspec files themselves, the resulting package will be referenced instead. Finally, point the OutputDir to a path where you want the package to end up.

Automate all the things!

With a Visual Studio solution set up, we can now integrate the packaging process in our CI builds and be merry. 

Good luck!

Troubleshooting

Using these packages in some of our projects caused issues. Some project couldn't find types we knew were in the NuGet packages and some projects claimed that they were referencing NuGet packages that were not available. The projects in questions were those who were loaded from several different solutions. After much pain and agony, I ran across this blog, which helped me get through: NuGet Reference Paths for Projects in Multiple Solutions by Mr. Jason Stangroome (). Thanks! :-)

Comments

Post a Comment

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Image
TL;DR: Yes, they will. Thank you for your time. 😄 Background At Redgate, engineers enjoy a great benefit in that we get are expected to spend 10% of our time to improve on our craft.  Having suffered this week with manually having to copy a bunch of properties from a domain object to its HTTP representation, I decided to spend this week's 10% time to see if I could answer the following questions: Can use AutoMapper to simplify mapping between two types?  Does it also allow me to map between a regular type and a record type? What about the other way around? Can I use this to reduce the maintenance burden in my product? Mapping between two types [automapper fundamentals] To started and get a basic mapping done, created a .NET 5 ASP.NET Web API project, added the below package references and configured automapper : < PackageReference Include ="AutoMapper" Version ="10.1.1" /> < PackageReference Include ="AutoMapper.Extensions.Microsoft.DependencyInj
Read more

Unit testing your Azure functions - part 2: Queues and Blobs

In our last installment , we discovered how to start unit testing our Azure Functions, looking at the HTTP Trigger (and evaulating the function's HTTP response). This time, we'll take a look at using the QueueTrigger, getting supporting data from table storage and outputting Blobs. Yup, I'm tossing you into the deep end! What are we trying to accomplish? This time, we will test a function that performs some arbitrary business logic on bank accounts. The function responds to a storage queue request, logs each command and ensures that each received command is executed exactly once. Almost like a real-world function, huh? ;-) In the function above, we are introduced to three types that we need to deal with in our unit tests - the IQueryable interface, IAsyncCollector and the CloudBlockBlob concrete type. IQueryable is easy enough to work with: Introducing the Testable Async Collector When I first started exploring this topic, I figured I could just use my favourit
Read more

Testing WCF services with user credentials and binary endpoints

Image
This article discusses the following error messages that you might receive from a WCF service An error occurred when verifying security for the message HTTP/1.1 415 Cannot process the message because the content type 'application/soap+xml;charset=UTF-8;action="..."' was not the expected type 'application/soap+msbin1' When doing analysis work on existing services, invoking them in a safe test environment is a handy way of getting an understanding of their operations, especially if the documentation has gone missing (or was never written). SoapUI is a tool that can be used to test WCF Services, but did you know that Visual Studio also comes with its own set of tools? Let's start with SoapUI, which is available from  http://www.soapui.org/ . Its operations are quite straight-forward; however, you might run into issues when trying to access services that are protected by user credentials, or when accessing services with binary endpoints. I
Read more