This Code Bytes

Programming Tidbits

30. March 2013 16:45
by Brad Falk

Consuming a NuGet package from a private NuGet feed

30. March 2013 16:45 by Brad Falk | 0 Comments

In the last post I showed how you can create a custom NuGet package using the NuGet Package Explorer. This post will show how to create a simple private NuGet feed and consume the packages in that feed in Visual Studio.
Here are the steps involved:

  1. Create the private feed – in our example this will simply be a folder out on a network share.
  2. Notify the Package Manager in Visual Studio know about the private feed.
  3. Install the package in your project via the “Manage NuGet Packages” interface.
Create the Private Feed

There are plenty of references on the internet for creating your own NuGet feeds, including this one from the NuGet documentation. If you read that you’ll see that a private feed can be as simple as a local folder or you can host a remote (or internal) feed with a web application using NuGet Server. What I’m going to show here is sort of in between the two, using a folder on a network share so that it can be shared amongst the team, and keep it simple at the same time.

So, you can see from the screenshot below that I created a NuGet Packages folder, under a Development share on MyServer, and I copied over the NuGet package that I created in the last post:

Guess what? We’re done! That’s all it takes to create a “feed” that we can point Visual Studio at so that it’s aware of our packages.

Configure Visual Studio

Now we need to let the Package Manager in Visual Studio know about this feed. In Visual Studio go to Tools –> Options –> expand the Package Manager node in the left pane and select Package Sources.
From here, click the Plus button at the upper right, give your feed a Name and a Source path – as you see I gave it the path to the network folder from the previous step:

Click Ok and that’s all there is to it. Now Visual Studio is aware of your feed and you’ll be able to install packages from that location.

Install the Package in a Visual Studio project

Okay, now let’s finally get down to reaping the benefits of our work. To install the package just right click on the references folder in the project that you wish to use the package, and select the Manage NuGet Packages option:


This will open the Manage NuGet Packages dialog. Notice that under the ‘Online’ section in the left pane, you should see the custom feed we installed in the previous step and the middle pane should contain our custom Kendo package:


Just click the Install button next to the package name and all of the files should be pulled into your project, and we’ll have the result we were looking for in the last post:


Updating the package

Updating the package to a new version is also a breeze using NuGet. Coincidentally, Telerik released a new version of Kendo UI since my last post. So, I created a new package, with the latest Kendo version, using the same steps as my last post and copied that new package into my private feed location:

Now, when I go into the Manage Nuget Packages dialog, and switch over to the Updates section, I should see my new package show up:


What’s happened here is that the NuGet Package Manager has detected that one of the packages that I have installed in this project has a newer version in our feed. So, now we just have to click the Update button and NuGet will pull down the new version of the package and update the files in our project with the new version. Doesn’t get any better.

Summing Up

Hopefully I’ve been able to show some of the coolness of NuGet and demonstrate how easy it is to create your own packages, private feeds and bring all of that together to manage the dependencies you have on third party tools that don’t already have packages out on the official NuGet package source.

19. March 2013 19:19
by Brad Falk

Creating a Kendo UI NuGet Package with NuGet Package Explorer

19. March 2013 19:19 by Brad Falk | 0 Comments

NuGet Rocks

As most people know by now, NuGet is an awesome package management system, with nice Visual Studio integration, that makes it a snap to pull third party libraries into your project. Installing a Nuget package can result in something as simple as putting a single file in the root directory or as complicated as adding a full directory structure, with multiple files, adding dll references and updating config files.

What I want to demonstrate in this post is how easy it is to manually create a NuGet package and consume that package from a simple private NuGet feed. More specifically, I want to demonstrate how you can leverage NuGet to manage the dependencies on the third party libraries that you’ve purchased that don’t already have NuGet packages out on the official public NuGet package source.

Packaging Kendo UI

I’m using Telerik’s Kendo UI suite of HTML5/JavaScript widgets on my current project – it’s a great way to jumpstart UI development and add a nice polish to your application. To use Kendo UI you need to include JavaScript files, CSS files and a set of images in your project. Additionally, I’m using the MVC wrappers that Telerik provides, so that you can configure the widgets using C# and it will emit the proper HTML and JavaScript. The wrapper is housed in a dll, so you’ll also have to add a reference to that into your project as well. If we had a NuGet package, we could have all of this added for us, with a click of a button.
At the end of the day, this is what we want our project to contain:


So why do we need to go to the trouble of creating a NuGet package for this? Can’t we just manually copy the JavaScript and CSS into the project, and add a Third Party/lib folder in the solution root for that dll reference? Absolutely. And that would work great. But there are a couple of reasons why I favor NuGet for this:

  1. I’m already using NuGet to manage my other third party dependencies – things like JQuery, Ninject, and all of the Microsoft packages that came with the MVC project template. So it’s nice to keep things consistent – they’re all in the same place.
  2. Telerik releases a new version of Kendo UI every quarter. When I want to upgrade my project, I just need to create a new version of the NuGet package and pull everything in via Visual Studio. This really becomes a benefit if I have more than one project that’s using Kendo UI. I can now just walk up to each of those projects and update them with a single click instead of having to copy the new files into each of the directories by hand. This helps eliminate error.

Alright – enough talk – let’s create a package.

NuGet Package Explorer

The NuGet Package Explorer is an awesome tool for creating new packages as well as examining the contents of existing packages. You can download it here from CodePlex.

When you fire up Package Explorer, you’ll be prompted for which task want to perform – choose Create a new package:


This will open the following window:


This is where all the good stuff happens. The left pane is where you’ll set all of the metadata about this package, and the right pane is where you’ll build the contents of the package. Let’s start with the metadata first.

Package Metadata

Click the Edit Metadata button in the Package metadata toolbar:

This will cause all of the fields to become editable:


Most of the properties here are pretty self explanatory, but one that I’d like to point out is the Version property. Like I mentioned earlier, I’m using the MVC wrapper for Kendo UI, which includes a dll. I’ve decided to tie the version of my NuGet package to the version of the Kendo MVC wrapper dll. This will let me know, at a glance, which version of Kendo UI that this package is related to. This saves me from having to invent my own version, plus it’s also a natural choice considering that the script and CSS files that we’ll be including are also tied to that version of the dll.

Click the green checkbox to save the metadata changes.

Let’s move on to building the package contents.

Package Contents

Right click on the right pane – you should get the following menu:

The two options that we’re interested in here are Add Content Folder and Add Lib Folder. When you add a Content Folder, anything that you put in that folder will be copied into your solution – we’re going to use this option for the Kendo UI JavaScript and CSS files. A Lib folder is used for library’s that you want to have references to in your project – we’ll use this option for the Kendo UI MVC wrapper dll.

Go ahead and add a Content Folder and a Lib Folder.

Now lets add in the Kendo UI web files. Right click on the content folder and choose Add New Folder. Add a folder named Content. Right click on the new Content folder you just added and add a Kendo folder under that – this is where we’ll put the CSS files. Next, right click on the top level content folder and add folder called Scripts, then right click on that folder and a new folder called Kendo – this is where we’ll put the JavaScript files.

Your Package Contents window should now look like this:

In windows explorer, browse to where the Kendo UI CSS files are installed. For me, this was:
C:\Program Files (x86)\Telerik\Kendo UI for ASP.NET MVC Q3 2012\src\styles  (the path will depend on what version you have installed). 

From here you can literally drag the files that you want in the package into the Package Contents window. I’m going to use the default Kendo template, so drag the default folder into the Kendo folder that’s under the Content folder, then do the same for the textures folder. And, finally, do the same for the kendo.common.css and kendo.default.css files.

Now let’s add the JavaScript. In windows explorer, back up a level, then drill into the js folder. From here, drag the following files into the Kendo directory that’s under the Scripts folder: kendo.web.js and kendo.aspnetmvc.js

Your Package Contents window should now look like this:

Note – I’m using the un-minified versions of these files because I’m going to let ASP.NET’s bundling and minifying handle that for me. You should use the minified versions otherwise.

Next, we’ll add the Kendo wrapper dll. In windows explorer, back up a level again, then drill down into wrappers\aspnetmvc\Binaries\Mvc3. That folder should contain a Kendo.Mvc.dll – drag that file into the lib folder in the Package Contents window.

Your Package Contents window should now look like this:

That’s it! Go to File –> Save and choose a location to save your new package:


Notice, by default, the file gets names with the package ID and version specified in the Package Metadata window.

Well, this post has already gotten long enough, so in the next post I’ll demonstrate how to setup a simple private NuGet feed and consume our Kendo UI package in an MVC application.

3. February 2013 07:23
by Brad Falk

Hello Blog World!

3. February 2013 07:23 by Brad Falk | 0 Comments

Yes, I know, if you had a nickel for every nerd who started their tech blog off with "Hello World" you'd be rich. I've never been known for my originality - sue me.

With that said, welcome to my blog. My name is Brad Falk, I'm a lead developer/software architect at NetWise Technology, working in the Microsoft .NET space. I've been doing web development since 1999, starting out doing mostly frontend work, writing tons of JavaScript way before it was cool to write JavaScript. I'm currently in the early stages of taking a 10+ year old web forms application, that primarily only works in Internet Explorer, and rewriting it in ASP.NET MVC 4, with all the HTML5 goodness and <insert buzz words here> that enable cross browser/device, etc. This is an awesome challenge that I'm really licking my geek chops over. Most of what I'll be blogging about over the next year will be things that I've learned throughout this project. It's going to be fun.


I actually put this site up over this past Thanksgiving break. I've been wanting to start a blog for quite a while and just never "got around to it". So, with some free time, I bought the domain, signed up for the hosting, downloaded BlogEngine.NET, and got the site up and running within a few hours. It felt great to finally do it. Coincidentally, the week after I put the site up, at our weekly team breakfast meeting, we listened to a short audio presentation by John Maxwell about falling into the trap of always just thinking about doing things, but never actually doing them...the "Ready...aim...aim...aim" syndrome - never pulling the trigger. I'd fallen into that trap, big time, in regards to the blog I always wanted to do. It was good to hear that other people do the same thing, and it felt awesome that I had just pulled the trigger on a goal I had been aiming for, for quite some time.


Well, here I am, almost three months after creating the site, with my blog still idle - the temporary "Under Contruction" post patiently waiting for me to take it down and write the real "Welcome to my blog" post. I actually stressed quite a bit about what this first post should be. I don't know why I thought it needed to be some grand work of art. Heck, even one of my favorite blogger's first post wasn't anything to look at.

So, now I've officially pulled the trigger, and I'm excited to have finally kicked this thing off!!

....for real this time, I promise.  Embarassed