by Martin Thern
Recently I was struggling with how to share and re-use code between my current client projects. An easy copy-paste of the code wasn’t an option, off course, since I don’t want any duplicated code. I could probably create a separate solution with the code I want shared and branch that code from our source control to the projects that need the code. As soon as I thought of this option I saw problems with people forgetting to merge back any changes in the shared code.
Pretty soon it came clear to me that I just wanted to share the binaries. A simple solution would be to copy-paste my binaries. But since it does happen that we make changes to the shared code it would be easier with some kind of infrastructure that supports updates. The answer to my problem is called NuGet!
NuGet is an extension for Visual Studio 2010 that makes it a joy to install and update third-party libraries, and this can also be used for internal libraries. More about NuGet and how to use it can be found on NuGet.
To show you how I implemented this, I will use a simple project that contains an INinja interface and a .nuspec-file. The .nuspec-file specifies how the NuGet package should be generated (more about package generation in the NuGet Docs).
In order to generate a NuGet package you need to download the NuGet Command Line from Codeplex (the file is included in the code sample).
In the root folder of the solution I have added a bat-file with the following content:
What this does, basically, is that it starts with building the package with my project file as the source. The xcopy command copies the generated .nupkg-file to my file share (in this case it’s the Packages folder, but could of course be a network file share and there is also a NuGet server available as a NuGet package). The del command cleans up the created files in the local folder.
To be able to take advantage of your new awesome NuGet package you only have to go to the NuGet settings in Visual Studio and add a new package source with the path to your share (in this case the Packages folder).
If you update the source code in your package, all you have to do is to update the version number in the projects assembly information and rebuild and publish the NuGet package. Then there will be a new version of the library for all the consumers to upgrade to.
If you are making daily changes in the shared code then probably this isn’t the best and most efficient solution, but it seems to be working good when it isn’t updated that frequently. The greatest part of it, is that you can say “Hey, there’s a NuGet for that!” when someone in your team wants to copy your awesome code ;)
Please feel free to check out the code sample on GitHub and drop a comment or suggest any improvements below. I’m already planning on letting our CI environment take care of both the generation and publishing of our packages.
About this blog
We at tretton37 believe in having a strong company culture that promotes craftsmanship, professionalism and knowledge sharing.
We want to use this blog to share what we know and give everyone insight into our thoughts.
Here is the RSS link for this blog:
- October 2013
- July 2013
- May 2013
- April 2013
- February 2013
- November 2012
- October 2012
- September 2012
- August 2012
- June 2012
- May 2012
- April 2012
- January 2012
- December 2011
- November 2011
- September 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- October 2010
- August 2010
- July 2010