MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

MyGet logo stickers

We're fairly sure the mailman didn't know he was carrying more than one package this morning when handing over the enveloppe. To celebrate our new logo, we've been handing out free subscriptions to our Starter plan during the past few days. Follow us on Twitter for future announcements (our Features page is growing!) and perhaps a chance to win.

Today we're happy to announce we'll be handing out some of these cool stickers during our upcoming trips! Thank you StickerMule for a job well done!

Want to get some? Then don't miss the opportunity to meet our team members and learn how we built MyGet at these upcoming events:

See you there & Happy Packaging!

Update project templates to the latest NuGet packages

We noticed a question on StackOverflow that proved we weren't the only ones finding it a little sub-optimal having to update NuGet packages right after creating a new project.

Most of us are likely to use the default project templates that come with Visual Studio or an SDK. Let's take the example of the MVC4 project template for C#, using Razor syntax.

MVC4 C# Web application template using Razor syntax

 

This project template is consuming quite a few NuGet packages by default. jQuery is one of them. The whole point is that these NuGet packages can be updated more frequently and independent from any pending SDK update or other product release. This is a good thing!

As a direct consequence, this also means that the default templates become "outdated". Outdated is a strong word, as the template itself isn't really outdated, but rather the packages list it wants to consume from NuGet. jQuery is one of those packages that gets very frequent updates. There's an easy way to update all packages in a solution all at once. Use the Package Manager Console, type

Update-Package

and hit ENTER. Done!

But why not avoid this step (or at least partially) and change the defaults?

Note: We'd recommend you to create your own project template so you can always revert back to the default one in case you, or someone else, is going to mess things up :)

All Visual Studio (2012) project templates can be found here:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\

If you want to create some custom project templates, I'd recommend you to create them here:

%USERPROFILE%\Documents\Visual Studio 2012\Templates\ProjectTemplates

In this post, we'll show you how you can change the defaults for the MVC4 CSHTML project template. You can find it here:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033\MvcWebApplicationProjectTemplatev4.0.cshtml\

To modify the files, you'll have to edit them as Administrator (you know the drill, right-click Notepad++ or Sumblime and click Run As Administrator).

The file you'll want to take a look at is the .vstemplate file. It's an XML file containing template instructions for Visual Studio. Look for a section called packages. It should look something like this:

<WizardData> 
<packages repository="registry" keyName="AspNetMvc4VS11" isPreunzipped="true"> 
<package id="EntityFramework" version="5.0.0" skipAssemblyReferences="true" /> 
<package id="jQuery" version="1.7.1.1" />
...

Let's take jQuery as an example again: we want to upgrade the dependency to version 1.8.2 by default.

To do so, you modify the above snippet to look like this:

<WizardData>
<packages repository="registry" keyName="AspNetMvc4VS11" isPreunzipped="true">
<package id="EntityFramework" version="5.0.0" skipAssemblyReferences="true" />
<package id="jQuery" version="1.8.2" />
...

Easy huh?

Now you found the candy, you can change the default installed package versions, or even add or remove the packages you want. Whatever you do, make sure you don't break the template so proceed with caution. If you remove a package dependency, make sure you remove any dependent configuration or references in the project template's files. If you update a package to a newer version, make sure those dependent configurations are updated as well.

Take a look at the project template's Scripts folder. You see that little _references.js file?

This is a harmless example of things that can be left behind and out-of-sync with the package edits you make. Open the file (run as administrator) and update those references accordingly. The jQuery reference should now be the following:

/// <reference path="jquery-1.8.2.js" />

Ever wondered why you didn't have to be online to be able to create a new MVC project and consume all those packages? Then check this folder and be amazed:

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Packages

Obviously, the packages you want to support in your default project templates should be available there as well, so download those NuGet packages and extract them here. You can download the NuGet package after logging in to NuGet.org: look for the package you want, select the version you need, and you'll notice a download link on the left side.

Download a NuGet packages from the Gallery

Once downloaded, unblock the package (right-click, properties, unblock), copy it to the packages directory (C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Packages). Next, unzip it, and remove all garbage. The relevant content is selected on the following screenshot. Ensure you rename the .nuspec file by adding the version in front of it, e.g. jquery.1.8.2.nuspec.

Relevant package contents

From now on, all newly created default MVC4 CSHTML Web projects will already contain the updated jQuery dependency.

How we push GoogleAnalyticsTracker to NuGet

If you check Maarten’s blog post Tracking API usage with Google Analytics, you’ll see that a small open-source component evolved from MyGet. This component, GoogleAnalyticsTracker, lives on GitHub and NuGet and has since evolved into something that supports Windows Phone and Windows RT as well. Here’s his guest post:


It’s funny how things evolve. GoogleAnalyticsTracker started as a small component inside MyGet, and since a couple of weeks it uses MyGet to publish itself to NuGet. Say what? In this blog post, I’ll elaborate a bit on the development tools used on this tiny component.

Source code

Source code for GoogleAnalyticsTracker can be found on GitHub. This is the main entry point to all activity around this “project”. If you have a nice addition, feel free to fork it and send me a pull request.

Staging NuGet packages

Whenever I update the source code, I want to automatically build it and publish NuGet packages for it. Not directly to NuGet: I want to keep the regular version, the WinRT and WP version more or less in sync regarding version numbers. Also, I sometimes miss something which I fix again 5 minutes after. In the meanwhile, I like to have the generated package on some sort of “staging” feed, at MyGet. It’s even public, check http://www.myget.org/F/githubmaarten if you want to use my development artifacts.

When I decide it’s time for these packages to move to the “official NuGet package repository” at NuGet.org, I simply click the “push” button in my MyGet feed. Yes, that’s a manual step but I wanted to have some “gate” in the middle where I should explicitly do something. Here’s what happens after clicking “push”:

Push to NuGet

That’s right! You can use MyGet as a staging feed and from there push your packages onwards to any other feed out there. MyGet takes care of the uploading.

Building the package

There’s one thing which I forgot… How do I build these packages? Well… I don’t. I let MyGet Build Services.do the heavy lifting. On your feed, you can simply click the “Add GitHub project” button and a list of all your GitHub repos will be shown:

Build GitHub project

Tick a box and you’re ready to roll. And if you look carefully, you’ll see a “Build hook URL” being shown:

MyGet build hook

Back on GitHub, there’s this concept of “service hooks”, basically small utilities that you can fire whenever a new commit occurs on your repository. Wouldn’t it be awesome to trigger package creation on MyGet whenever I check in code to GitHub? Guess what…

GitHub build hook

That’s right! And MyGet even runs unit tests. Some sort of a continuous integration where I have the choice to promote packages to NuGet whenever I think they are stable.