NuGet Productivity Hack

This article explains how with a couple of quick hacks you can gain a little extra productivity when using NuGet.  The hack it's self is simple, Just add NuGet's local cache as a feed.  It turns out this can save you time, keep you team mates on side and even improve your presentations.

Originally I did this to help with development of API's that develop and use in house.  We were facing a problem with rapidly increasing version numbers when initially developing an API for the business logic of our product.  Each developer was working on one vertical slice of the product meaning that they may have to tweak the API if they found something that they hadn't considered in one of the layers of the application.  The simplest way to develop the package dependent on the API is to update it with NuGet. 

Our process for getting packages into the shared NuGet repository is simple.  We publish packages to NuGet after a build on our Continuous Integration server.  That way we know that each build has passed tests and that each package is as stable as it can be.  We follow Semantic Versioning and our rule is once it's in NuGet it's published.  So any change to the interface after that point means that the version number needs to change.

So in order to include a package into the dependent project without first pushing it through the NuGet process I needed to publish it locally.  I had to pick somewhere so I thought why not into the local cache. This way I don't need to keep tabs on somewhere else in the system and as long as the version of the package that I finally pushed to CI was the same as the last one I pushed locally or had a higher version number then NuGet would take care of making sure that what I was developing against was the same as everyone else. Unless of course it explicitly wasn't.

Great, with this I was able to develop an API, change it as often as I wanted while making sure it integrates smoothly with the dependent package and not ramp the version numbers up needlessly.  Awesome! that's some productivity bonuses right there.  No more waiting for the slow build server to build and publish the package.  No more annoying the rest of the team with increasing versions and breaking APIs.

But this is all expected, it's the desired outcome of the problem I had.  I got a pleasant surprise as I kept working.   With the local cache at the top of my NuGet repositories list it was loaded up first when I went to add a new package.  Because it's accessing the local disk, an SSD, it was almost instant to load the add packages dialogue.  I'm not sure if serving the package list is universally slow or if it's our internal infrastructure but I found that this saved me several seconds and a fair bit of frustration when going to add commonly used internal and external NuGet packages. This may not save too much time but it does save a little frustration waiting for the NuGet dialogue.

Bonus!

The other day while attending the local Newcastle Coders Group we had Internet access issues, rather par for the course at the University of Newcastle.  These issues inhibited the presenter from being able to add the packages he required in order to do his demonstrations.  This might normally have stalled the presentation.  Instead I was able to get him to hook up his local cache as a repository and continue with the presentation.

So there we have it.  Publish packages to a local NuGet feed and avoid annoying your team members.  Make that feed  your local cache to speed up your daily development in adding regularly used packages to projects.  Use the local feed to have access to regularly used packages when for some reason you have no internet access. 

Comments

Post a Comment

Popular posts from this blog

Solving `Empty reply from server` in DotNet Core

tldr; If you’re getting  curl: (52) Empty reply from server  check that you’ve configured Kestrel correctly. Long version I’ve started playing with Dotnet Core and Docker and have had a few issues getting started. I’ve had a little bit of experience with Docker, though only a little. I’ve worked with DotNet previously but never with Core. Environment The setup I’m using is a Windows laptop running Vagrant. Via Vagrant I’m running an Ubuntu Virtual Machine with the Docker run time installed. Feels a litle like inception. Key Problem The key problem that I’ve had getting started was having my Docker container not responding correctly to my curl commands. I get this: curl: (56) Recv failure: Connection reset by peer curl: (52) Empty reply from server Given that I’m not all that familliar with Docker or Dotnet Core I decided to remove one of the variables and set up a simple Express app in a different docker container. This validated that the commmand I was using to run
Read more

Testing functions that use local storage with Jest

Testing functions that use the browsers local storage API seems easy when you know how. Here's a quick run down on how to mock it out with Jest if, like me, you're not familiar with how to test it. In the end it's very little code. Consider the following TypeScript code. import { get, save, key } from "./storage"; describe(save, () => { let setItem: jest.Mock; beforeEach(() => { setItem = jest.fn(); Storage.prototype.setItem = setItem; }); it("should call set item with predefined key and json object", () => { const valueToStore = { value: "toStore" }; save(valueToStore); expect(setItem).toHaveBeenCalledWith(key, JSON.stringify(valueToStore)); }); }); The key lines are in the beforeEach call where the setItem function of the Storage prototype is assigned to an instance of jest.fn() . This allows us to make assertions on what is passed to the local storage setItem API.
Read more

Building a verify JWT function in TypeScript

# Verifying an RS232 signed JWT JSON Web Tokens (JWT) are used as a way to verify the identity of the caller of an API. **The best way to verify a JWT is to use a verification library.** I wanted to have a look at some of what those libraries are doing under the hood by putting together a function that will return if a given token is valid. In this blog I'll go through what I have done to get a validation function working. To simplify things assume: - That the signing algorithm is RS232 all others are considered invalid. - That the public keys are available on a JWKS url provided to the function eg [https://klee-test.au.auth0.com/.well-known/jwks.json](https://klee-test.au.auth0.com/.well-known/jwks.json) - I only want to know if the token was signed by a key available at the above url. I wont be checking if the token has expired, if the scopes or other claims are valid. # Break up the token A JWT is made up to 3 parts. The first thing to do in validating the token is to brea
Read more