We've gone from tretton37 to 13|37.

We’re still the same company with the same heart and focus on empowering clients and colleagues – and that will never change – but now we’re shorthand! If you want to get in touch to talk to us about empowering your organisation, uncovering your digital capabilities or find out more about life at 13|37 then head on over to 1337.tech.

tretton37.com will be available for a limited transition period only. Have a wonderful day.

Visit us at 1337.tech

Hey, there's a NuGet for that!

Posted 2011-06-10 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.

Shameless plug: We are a very unique family of driven software-creating professionals.

Join us. We are hiring in all our offices in 🇸🇪 Sweden & 🇸🇮 Slovenia.