Juri Strumpflohner
Juri Strumpflohner Juri is a full stack developer and tech lead with a special passion for the web and frontend development. He creates online videos for Egghead.io, writes articles on his blog and for tech magazines, speaks at conferences and holds training workshops. Juri is also a recognized Google Developer Expert in Web Technologies

Using NuGet to Distribute Our Company Internal DLLs

3 min read

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! :)

Questions? Thoughts? Hit me up on Twitter
comments powered by Disqus