Nuget packaging multiple projects

I have noticed a few people struggle when it comes to packaging multiple projects that exist in a single solution and I had a similar problem at work. Taking a look on SO you can easily find the work-around which is to use an additional Nuget command :


Now this works when you want to package up a project that references other projects and so on. But what if you had, lets say, 3 projects A,B and C and all 3 projects had to be packaged together? By the way, allowing them to be packaged separately just wasn’t an option.

  • Project A does not reference anything.
  • Project B references Project A
  • Project C references Project A

In this case what do we do? We want to package project A, but the above command wont work since A has no references. This means B and C wont be included.

Worry not as Nuget has us covered.

  • Got to the root directory of your solution.
  • Add a nuspec file, you can find a template pretty much anywhere.
  • Add the following lines after the metadata section
    <file src="..\src\ProjectA\bin\Debug\netstandard2.0\*.dll" target="lib\netstandard2.0\" />
    <file src="..\src\ProjectB\bin\Debug\netstandard2.0\*.dll" target="lib\netstandard2.0\" />
    <file src="..\src\ProjectC\bin\Debug\netstandard2.0\*.dll" target="lib\netstandard2.0\" />

All this does is tell Nuget exactly which dll’s you want packaged up. Turned out to be pretty simple in the end.

Immutable types in C#

Ever sat in a meeting with a bunch of devs and suddenly you hear the words ‘immutable type’ and your head explodes because what the heck is that?

It is a type of object whose data can’t be changed after its been instantiated. The string and Datetime classes are good examples.

If you weren’t aware, once you create a string, you cannot change its value.
The string class essentially creates a new string object internally for all string manipulation actions you perform.

The same goes for DateTime. When adding a month or day onto Datetime we are creating a new Datetime as opposed to modifying an old date.


  • Thread Safety
  • Copying is fast and safe since the copy cant change either


  • Slightly more effort required in implementing. Potentially in the form of a builder class that would apply the operations, although many times this isn’t an issue
  • Potential performance degrade when continuous changes are made (this would be more noticeable on objects that take up a lot of memory)

I have only summarised the very basics of Immutable types. My conclusion is use an immutable type for something that you know wont change.

Example: If you have a blob of text that is going to be displayed as a message and never change then use the string class. If you have a piece of text that you know you need to modify a lot then use the StringBuilder class instead.

Photo by Kristen Sturdivant