Using NuGet to Distribute Our Company Internal DLLs

Releasing new software has to be simple and super fast! That was not the case for our company-internal class libraries till a couple of month ago until I finally decided to take the time to optimize that release process.
At the company where I'm working at currently, we have an internal class library which bundles a series of utilities with the scope of helping devs doing their day-to-day job. So far so good, however, there has always been a thing that  puzzled me right from the beginning was the cumbersome release process of that library. Creating a release bundle consisted in
  • incrementing the version number in the AssemblyInfo
  • building the library project in release mode
  • opening the bin folder
  • zipping the dlls
  • uploading the zip to our company-internal wiki page with a version history of the release
That's really tedious, isn't it? It sometimes took longer to create a new release than to fix a bug. So a couple of months ago I decided to optimize that: using NuGet. If you're a .Net dev you for sure already heard about it.
NuGet is a Visual Studio extension that makes it easy to install and update third-party libraries and tools in Visual Studio. When you use NuGet to install a package, it copies the library files to your solution and automatically updates your project (add references, change config files, etc.). If you remove a package, NuGet reverses whatever changes it made so that no clutter is left.
The idea was to create a local, company-internal NuGet repository.

Setting up a company-internal NuGet Repository

That turned out to be simpler than expected. Creating a local NuGet repository is as simple as creating a folder on some network share and to deploy all of your NuGet packages there.

Configuring Visual Studio

In order for NuGet to also search on your private repo you need to add the URL to the repository in your NuGet Package Manager Settings under Tools > Library Package Manager > Package Manager Settings.

When you now invoke the Nuget Package Manager on a Visual Studio Project or Solution you should also see your private repo listed as a possible source:

You're ready! You can now start packaging your class libraries and dlls as NuGet packages.

Automate to the death?

I'm not going to write on how to create NuGet packages as NuGet has excellent docs on this. What I did is to create a .nuspec file for the class library and then a nice publishRelease.bat containing something like
msbuild Siag.Base.csproj /target:Rebuild /property:Configuration=Release 
nuget pack Siag.Base.csproj -Symbols -Prop Configuration=Release
move *.nupkg \\snip\snip\NuGetRepository

Releasing today means...

  • Incrementing the version number in the AssemblyInfo.cs
  • double-clicking on the publishRelease.bat
Like it! :)


  1. Hello, nice article. I am just now researching the same thing. Looking at this, I am wondering whether or not you would need the 'msbuild' step in your batch file since nuget contains the -build flag? Thanks.

  2. Hi,

    really? Didn't check for that but thx for the hint, I'll try it for sure.

    For the rest, I can just recommend this approach. We've been using it now for a couple of month and it's awesome!

  3. Hi, I was also involved in deploying a forked nuget to our company as a dependency management system. Yet, it involved more work to get what we wanted. So, we performed:
    1. extended nuget extension (hooked into postbuild solution event which is not given offhand in VS. This post build solution event was supposed to create a packages (consisting of specific libraries - we managed it by creating projects in different folders) and then publishing it (by simply copying) to our developer's local nuget feed.
    2. In extended nuget extension we have also created additional cmdlets like 'switch-ToLocalDependency' so that we could easly change referenced original libraries to our-locally-build-version which allowed us to speed up testing complex solution.
    3. Last but not least - we integrated deploying nuget packages to company repository on teamCity build server. So that each new release version was automagically added to repository.

    Still it's great and powerfull tool which hopefully will get more and more features with each new release.