MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

How SharpDevelop uses MyGet and NuGet

This is a guest post by Matt Ward, working on SharpDevelop, an open source Integrated Development Environment (IDE) for .NET applications which supports the development of applications written in C#, Visual Basic.NET, F# and IronPython. It is and written in C#. In this post, Matt shares their story on using MyGet to host and discover add-ins for SharpDevelop.

If you would like to share your story too, let us know! We love to hear good stories!

SharpDevelop NuGet MyGetThe SharpDevelop team recently announced a new Addin Manager for SharpDevelop 5 and an online gallery for addins that is hosted on MyGet.

SharpDevelop has been extensible through addins since it was first created but it has never before had an online gallery. The majority of IDEs have an online gallery that can be used to find and install extensions. WebMatrix is one example that provides extensions through from its own NuGet feed just like SharpDevelop.

Addins for SharpDevelop 5 can now be published as NuGet packages to a MyGet gallery. NuGet gives SharpDevelop all the benefits of versioning and updating addins whilst MyGet provides a central place where SharpDevelop addins can be found and installed from.

SharpDevelop's addin gallery on MyGet is a community gallery which is open to anyone to publish their own addins.

Background

About a year ago there was a discussion on the SharpDevelop mailing list about having an online source of addins for SharpDevelop. Andreas Weizel had started work on a way to obtain addIns from an online source but at the time it was not based on NuGet. Christoph Wille, Project Manager for SharpDevelop, suggested looking at re-using the NuGet gallery for hosting the packages and using NuGet to download and install addins. One idea was to put the addins on the main NuGet.org feed and add a special tag to them to distinguish them however it made more sense for SharpDevelop to have its own gallery. Rather than setting up a server and hosting a NuGet gallery ourselves it was quicker and easier to use MyGet.

Now let us take a look at how you can make your own addins available for SharpDevelop 5. If you have published a NuGet package to the gallery hosted on NuGet.org then the following procedure will be very familiar.

Publishing an Addin with MyGet

Here we will look at the steps taken to publish an addin that provides support for compiling against Mono. The source code for this sample addin is available on GitHub. The first step is to compile the addin. With the Mono addin compiled we need to create a .nuspec file that will be used to generate a NuGet package containing all the files needed for the addin:

    <?xml version="1.0"?>
    <package xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <metadata xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
            <id>Mono</id>
            <version>1.0</version>
            <authors>Matt Ward</authors>
            <owners>SharpDevelop</owners>
            <requireLicenseAcceptance>false</requireLicenseAcceptance>
            <description>Mono support for SharpDevelop</description>
            <iconUrl>http://community.sharpdevelop.net/blogs/mattward/SharpDevelop.png</iconUrl>
            <summary>Mono support for SharpDevelop</summary>
            <releaseNotes></releaseNotes>
            <language>en-US</language>
            <tags>mono</tags>
        </metadata>
        <files>
            <file src="..\..\..\AddIns\Samples\Mono.Addin\**\*.*" target="" />
        </files>
    </package>

In the above .nuspec file we are adding all the addin files, including any subdirectories, by using the double wildcard ** so we do not have to explicitly specify every file. SharpDevelop requires the main addin assembly and its associated .addin configuration file to be in the root of the NuGet package. This is why the target for these files defined in the .nuspec file has been left empty.

Now we can generate the NuGet package by running NuGet.exe from the command line:

nuget pack mono.nuspec

On running this command you will see a "Assembly outside lib folder" warning which can safely be ignored since we are not going to be adding this NuGet package to a .NET project. We have now generated a Mono.1.0.nupkg file which is what we will publish to the MyGet gallery.

To publish to MyGet you will need your MyGet account's personal API key. Your API key can be found under Account Settings in the Security section. Copy your API key and in the following command line replace the Your-API-Key with your key:

Running the above command will publish the Mono addin to MyGet. Now anybody using SharpDevelop 5 can install the Mono addin by selecting AddIn Manager from the Tools menu.

image

You can see the list of available addins by clicking the Available section of the dialog. To install the Mono Addin select it and click the Install button. The addin will be available after SharpDevelop is restarted.

Matt Ward is developer at Pebble Code. In his spare time he works on SharpDevelop, which he has been involved with since 2004, and more recently has been working on a NuGet addin for MonoDevelop and Xamarin Studio.

Blog: community.sharpdevelop.net/blogs/mattward Twitter: @sharpdevelop

Create a list of favorite ReSharper plugins

With the latest version of the ReSharper 8 EAP, JetBrains shipped an extension manager for plugins, annotations and settings. Where it previously was a hassle and a suboptimal experience to install plugins into ReSharper, it’s really easy to do now. And what is really nice is that this extension manager is built on top of NuGet! Which means we can do all sorts of tricks…

The first thing that comes to mind is creating a personal NuGet feed containing just those plugins that are of interest to me. And where better to create such feed than MyGet? Create a new feed, navigate to the Package Sources pane and add a new package source. There’s a preset available for using the ReSharper extension gallery!

image_thumb[1]

After adding the ReSharper extension gallery as a package source, we can start adding our favorite plugins, annotations and extensions to our own feed.

image_thumb[3]

Of course there are some other things we can do as well:

  • “Proxy” the plugins from the ReSharper extension gallery and post your project/team/organization specific plugins, annotations and settings to your private feed. Check this post for more information.
  • Push prerelease versions of your own plugins, annotations and settings to a MyGet feed. Once stable, push them “upstream” to the ReSharper extension gallery.

Happy packaging!

Improved search syntax in NuGet client... and on your MyGet feeds

Yesterday, the NuGet team released some improvements to searching the official NuGet package source. Today, you can also use this new syntax on your MyGet feeds!

This new search syntax allows us to narrow our search to a particular attribute of a NuGet package. For example, we want to search for packages which contain “Glimpse” in the Id, we can type “id:glimpse”. We can also search the description of a package and check if it contains any of the given words. For example “description:twitter bootstrap” will yield packages containing either the word “twitter” or “bootstrap” in their description.

NuGet improved search syntax

Some example searches: (taken from the NuGet blog)

Attribute

Example

id

id:jQuery

title

title:Validation

description

description:dependency injection

authors

authors:Outercurve Foundation

tags

tags:silverlight

 

Enjoy, and as always…

Happy packaging!

Support for Package Source Discovery draft

We’re proud to announce support for the NuGet Package Source Discovery (PSD) draft on MyGet. Package Source Discovery (PSD) allows for NuGet-based clients tools to discover the feeds that are hosted by a user or organization by using the blog or website URL. Every feed hosted on MyGet has a discovery endpoint hosted at http://www.myget.org/Discovery/Feed/<yourfeed>.

In its simplest form, you can place a simple HTML tag on your website or blog and use that for discovering all feeds you own, whether on MyGet or another NuGet package repository such as TeamCity or the NuGet gallery.

Package Source Discovery

NuGet Package Source Discovery is an attempt to remove friction from the following scenarios:

  • An individual user may have several NuGet feeds spread across the Internet. Some may be on NuGet.org (including curated feeds), some on MyGet and maybe some on my corporate network. How do I easily point my Visual Studio to all my feeds accross different machines? And how do I maintain this configuration?
  • An organization may have several feeds internally as well as one on MyGet and some CI packages on TeamCity. How can this organization tell his developers what feeds they can/should use?
  • An organization may have a NuGet server containing multiple feeds. How will developers in this organization get a list of available feeds and services?

For all scenarios, a simple feed discovery mechanism could facilitate this. Such feed discovery mechanism could be any URL out there (even multiple per host).

As an example, open Visual Studio and open any solution. Then issue the following in the Package Manager Console:

Install-Package DiscoverPackageSources
Discover-PackageSources -Url "http://www.myget.org/gallery"

Close and re-open Visual Studio and check your package sources. The URL has been verified for a PSD manifest URL and the manifest has been parsed. Matching feeds have been installed into the NuGet.config file, in this case all feeds listed in the MyGet gallery.

Discovery for your feed(s)

By default, we’ve enabled discovery on your profile page. For example, http://www.myget.org/users/maartenba provides discovery for all my (public) feeds. Of course, you can also create your own discovery URL on your blog or website: simply add a <link /> element to the HTML code. From then on, you or your users can use the following command to discover feeds from your website or blog:

Install-Package DiscoverPackageSources
Discover-PackageSources -Url http://<your website>

On your feed’s discovery page, we’ve added the HTML you have to add to your website to enable this scenario.

image

Discovery for gallery feeds

We’ve added a discovery on the MyGet gallery. When using http://www.myget.org/gallery as the discovery URL, all gallery feeds will be registered in your NuGet.config file. Every feed on the gallery in itself also provides discovery, for example ScriptCS has a discovery endpoint at http://www.myget.org/gallery/scriptcsnightly.

Please provide feedback on the Package Source Discovery specification. Comments on the MyGet implementation are also welcome!

Happy packaging!

NuGet package restore from a secured feed

One of the most frequently asked questions at MyGet is the following one (we have pending updates to our FAQ section):

How do I set up NuGet package restore against a private MyGet feed requiring authentication?

This is also one of the things you might end up doing when debugging NuGet package restore issues.

For public feeds, you only need to change the repository URL in the nuget.targets file to let your build server know from where it needs to fetch the packages. For private feeds however, there are a few things you need to know.

Which credentials should I use?

At MyGet, we recommend you to create a separate account for your build agents and give it specific permission on your feed (e.g. readonly or read/write, but no additional permissions).

It is not a technical requirement though: you could simply use your personal account, but please be aware that in this case you share your credentials!

As you'll see in this post, you can store the credentials for the build service account on the build agent(s) without having to share them with anyone. Using a user's account for the build agent can break anyone's build if access for this user is revoked...

Visual Studio will prompt for credentials

As soon as you try to communicate with a secured package source in Visual Studio, it will prompt you for credentials. So why do you get the following build error when using package restore?

There's no non-interactive way to provide credential parameters

NuGet package restore relies on the NuGet.exe commandline tool by using the install command. The commandline will either prompt you for credentials (which isn't suitable for automated build scenarios), or will look for credentials in nuget.config file in %AppData%\NuGet\nuget.config (if you use the Non-Interactive option).

The latter looks like what you need in automated build scenarios, but requires you to store feed credentials on the machine, for the user account that will perform the build. This can become cumbersome if you have a multitude of solutions using this feature.

Hierarchical NuGet.config doesn't take credentials into account (yet!)

The latest version of NuGet has support for hierarchical nuget.config files, which is an attempt to overcome the need to store everything on the machine. It allows you to have a solution-level NuGet configuration which should be taken into account during package restore.

This means that feed URL and credentials could be stored next to your solution instead of being pre-configured in the user profile. However, credentials aren't picked up (yet), and there's no easy way to store them (encrypted) into any nuget.config file other than the one in your roaming user profile (explained in the next section of this post).

This is a known issue which seems to be fixed in vNext of NuGet. Check this Codeplex issue for more details. Not sure though whether this will be facilitated without having to copy-paste those encrypted credentials from one config to another.

You can store feed credentials in your user-profile NuGet.config

That's likely to be the easiest approach: as you register the package source URL, you might want to save the required credentials as well. This is however not exposed in the Visual Studio NuGet Package Manager extension, so you'll have to use the NuGet.exe commandline tool. The following gist illustrates a few of these options that should help you configure your secured feed, including credentials.

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.

MyGet Build Services - Public Beta

We’re happy to announce that MyGet Build Services is in Public Beta since, well, now. MyGet Build Services enable you to add packages to your feed by just giving us your Git, Mercurial or Subversion repo. We build it, we package it, we publish it. And starting today, every MyGet user can use it.

More information on MyGet Build Services can be found in a previous blog post, although some things have been updated. You’ve provided us feedback through our UserVoice, resulting in the following changes:

  • We now support .NET Framework 4.5. New features available in .NET Framework 4.5 are described at http://msdn.microsoft.com/en-us/library/vstudio/ms171868.aspx.
  • Build hooks! The list of your build definitions now shows a build hook URL which you can link to your GitHub or BitBucket repository. Calling this build hook (HTTP POST) will trigger a new build. Or in other words: a commit will trigger a build.
  • Our build server now checks for a file called build.bat first, then MyGet.sln, then your .sln and then .csproj/.vbproj files (UV)
  • We now support Git, Mercurial and Subversion repositories (UV)
  • You’ll now have some tools available in the environment variables (UV)
  • There’s more information in the build logs (UV)

Keep the feedback coming! Build Services are now enabled on every MyGet account. Do note MyGet Build Services are still a beta, and as Willy Wonka would say… “Little surprises around every corner, but nothing dangerous.”

Happy packaging!

PS: Why not deploy your freshly built apps using Octopus Deploy?

MyGet Build Services - Join the private beta!

Good news! Over the past 4 weeks we’ve been sending out tweets about our secret project MyGet project “wonka”. Today is the day Wonka shows his great stuff to the world… In short: MyGet Build Services enable you to add packages to your feed by just giving us your GitHub repo. We build it, we package it, we publish it.

Our build server searches for a file called MyGet.sln and builds that. No problem if it's not there: we'll try and build other projects then. We'll run unit tests (NUnit, XUnit, MSTest and some more) and fail when those fail. We'll search for packages generated by your solution and if none are generated, we take a wild guess and create them for you.

To make it more visual, here are some screenshots. First, you have to add a build source, for example a GitHub repository (in fact, GitHub is all we currently support):

MyGet Add build source

After that, you simply click “Build”. A couple of seconds or minutes later, your fresh package is available on your feed:

MyGet build package

MyGet package result

If you want to see what happened, the build log is available for review as well:

MyGet build log

Enroll now!

Starting today, you can enroll for our private beta. You’ll get on a waiting list and as we improve build capacity, you will be granted access to the beta. If you’re in, tell us how it behaves. What works, what doesn’t, what would you like to see improved. Enroll for this private beta now via http://www.myget.org/buildservices. Limited seats!

Do note it’s still a beta, and as Willy Wonka would say… “Little surprises around every corner, but nothing dangerous.”

Happy packaging!

PS: Why not deploy your freshly built apps using Octopus Deploy?