MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Labeling Sources when Pushing to NuGet.org

When adding package sources through your feed’s settings, a very nice scenario becomes available: the package promotion workflow. In other words: pushing a package from one feed to another. Or in other words: publishing nightlies to MyGet and promoting specific package versions to NuGet.org.

With the newly introduced labeling feature, it is now possible to label sources when pushing a package upstream. When enabled, MyGet will find the build from which the package originated and will add a label to the source control revision it was built from. Note that the build must originate from MyGet Build Services for this to work.

Choose the package you want to promote and with a click of a button you can push it upstream. A dialog will provide you with additional options, e.g. configure the package version to be used upstream.

Label sources when pushing upstream

An important note: If you want to make use of labeling, you will have to specify credentials to connect to the remote repository, or remove and add the build source again. Labeling will fail if this is neglected.

Let us know what you think about this feature through the comments below or in our forums!

Happy packaging!

GitHub Commit Status API now supported

A while ago, GitHub launched their Commit Status API which allows integrating the status of a build with commits and pull requests on GitHub. When a MyGet build source is linked to a GitHub repository and has credentials specified, we have started reporting status messages back to GitHub.

GitHub Commit Status API MyGet

When a build succeeds or fails, you will see a status message posted to GitHub, linking to the build log on MyGet.

MyGet reports build status to GitHub

To enable GitHub Commit Status messages on your builds, make sure the build configuration has credentials specified. Specifying credentials can be done by removing and adding the build configuration again, a method which doesn’t require you to enter your password. You can also specify credentials manually by editing the build source.

Happy packaging!

NuGet Package Restore and MyGet Build Services

With the release of NuGet 2.7, a new way of doing package restore came to life. Package restore allows you to keep only your source code and packages.config under source control and just download and install NuGet dependencies during build.

What does this mean for MyGet Build Services? Let’s say we’re making it easier for you! When building from a Visual Studio solution or project, there is nothing you should do: we will run package restore automatically. Let’s dive into the package restore conventions we have in place. Full details on the build process are available from our documentation.

MyGet Build Services

Package Restore Conventions

MyGet Build Services runs NuGet Package Restore as part of every build of solution or project files even if it's not enabled for the solution. Note that package restore is not run for builds making use of batch or PowerShell scripts. In those cases, you are the responsible for running package restore.

In order of precedence, the following package restore commands are run. When one succeeds, package other commands will be skipped.

  • nuget restore MyGet.sln -NoCache -NonInteractive -ConfigFile MyGet.NuGet.config
  • nuget restore MyGet.sln -NoCache -NonInteractive -ConfigFile NuGet.config
  • nuget restore <your solution file> -NoCache -NonInteractive -ConfigFile MyGet.NuGet.config
  • nuget restore <your solution file> -NoCache -NonInteractive -ConfigFile NuGet.config
  • nuget restore packages.config -NoCache -NonInteractive -ConfigFile MyGet.NuGet.config
  • nuget restore packages.config -NoCache -NonInteractive -ConfigFile NuGet.config
  • nuget restore MyGet.sln -NoCache -NonInteractive
  • nuget restore <your solution file> -NoCache -NonInteractive
  • nuget restore packages.config -NoCache -NonInteractive

If you are working with other feeds than the default NuGet.org feed, there are some options available.

Restoring from other Package Sources

If you want MyGet Build Services to restore packages from a specific feed, there are several options available to do this. The easiest way of making a package source available to the build process is by adding it through the UI.Making package source available during build

Using the Add package source button, you can add any feed that you want to make available during build: a Chocolatey feed, a TeamCity feed or another MyGet feed. It is even possible to store credentials so an authenticated feed can be used during build.

If you prefer to have all feed information in your source repository, that’s an option too. Adding a MyGet.NuGet.config file to your repository is the key to success. See the NuGet docs for more information on how such file can be created. The following is a sample registering a custom NuGet feed for package restore.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="Chuck Norris feed" value="https://www.myget.org/F/chucknorris/api/v2/" />
  </packageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
</configuration>

 

A small remark: if you have an authenticated feed but do not wish to add credentials to source control, credentials can be added to the feed's package source. These credentials will be available during build and allow you to consume a protected feed with ease. Authentication of feeds

Summary

Using NuGet Package Restore in MyGet Build Services is a breeze. We follow standard NuGet conventions to do your builds and allow adding package sources which will be made available during build through the UI. If you do need to customize things, there are several hooks available too. Full details on the build process are available from our documentation.

Let us know what you think about this feature through the comments below or in our forums!

Happy packaging!

Online gaming with OCTGN and NuGet

OCTGN online card and table game networkWe’ve been looking through some of the feeds that are hosted on MyGet and have found a nice use case for both NuGet and MyGet: the open-source project OCTGN, the Online Card and Table Game Network. As a result of that, we’ve had a chat with Kelly Elton, developer and maintainer of OCTGN.

Can you tell us a little bit about OCTGN?

“The title of the game kind of summarizes this, but OCTGN is a gaming platform that allows users to play card and board games with each other on the Internet. After installation, gamers get a virtual table top where they can download additional games from a repository, chat with other gamers and compete against each other.”

We’re assuming that the games repository is in fact a NuGet feed, is that correct?

Yeah, that’s an interesting one. Started using NuGet a while ago and it occurred to me that you could use NuGet as an application update system. It has metadata in there which you can query and the NuGet.Core assembly gives you a nice library for working with it.

Originally, our users would download an OPC (Open Packaging Conventions) file which is essentially a ZIP file. A NuGet package essentially also is an OPC package, so we were already using some form of packaging for distributing games before. And then we did some rework and tore some pieces apart and realized we could start packaging using NuGet to get things like searchable metadata, a formal upgrade system and so on.”

A lot of the games are card games, are you embedding the card artwork in the NuGet packages as well?

“No. Sets of cards can be 100 MB to 200 MB in size. Not all players will use all cards all the time and we don’t want game updates to download all artwork when it hasn’t changed between versions. Also we have a card proxy which generates images from card data on the fly if they don't exist, which allows us to cram a game that used to require 100MB of images to play into a 10MB package, with the option to download the cards from another source if they so choose.

We developed a system that allows you to specify the metadata for the cards which is kind of a specialized markup language and then download the artwork on-the-fly, only when needed.”

Who is developing the games for OCTGN? How can someone contribute?

In-game screenshot”Most of the games are developed by community members. OCTGN has been around since 2006 and has changed hands a few times but it’s essentially run by the community. I’m currently doing most of the development but I have some people helping me. The games themselves are developed by people, using Python and XML. We have a builder (o8build) which comes with OCTGN, takes the Python code and XML files and packages everything up so our game developers don’t have to know too much about NuGet themselves. There’s some info about that on our GitHub space.

Contributions are done in several ways. We have different NuGet feeds that are managed by game owners, we also have our official feeds that contain games that we want to be part of our system. You get added to that feed based on different metrics like game quality, how active development is and so on. There are different feeds maintained by other members of the community and they can take on some games as well.

We only host the official feed, but since it's so easy to get setup with MyGet, people in the community have had no problems at all setting up their own feeds.

Are all feeds public feeds?

“Some of our game developers asked if it would be possible to make a private feed for their games, we’re now looking into adding support for that in our client. We weren’t sure how we could authenticate the user towards these private feeds as the NuGet client libraries aren’t that well documented. But I’ve seen there is an ICredentialProvider interface in there we can probably use.”

How has your experience with MyGet been so far?

“Very good, we’ve enjoyed it quite a bit. We didn’t quite know if it was going to be the right system for the job at first as we were almost going to abstract away the way packages were offered to the game. Our big concern was that we have almost 40.000 registered users and we didn’t want to step on your toes with regards to package sizes, bandwidth consumed and so on. We wanted to make sure we weren’t causing any cause of problems as a free user of MyGet.

As far as quality goes we have absolutely had no problems with MyGet at all. It’s really easy to upload and manage packages and we’re now looking into using the build system you have as that’s pretty neat.”

As a last question, do you have any advice for people starting with NuGet or MyGet?

“For MyGet not so much as it can’t be more straightforward. Even people that didn’t know what NuGet was were able to setup feeds and upload their games in a matter of a minutes. That was really easy and I would encourage people to try it out. You guys are doing some awesome stuff!

One thing I’ve noticed with NuGet that tripped people up is versioning, sometimes the version numbers weren’t sorted in the way we’ve expected but we’ve tackled that. I believe Xavier had a blog post about this.

Another thing is most people seem to be focused on creating or consuming packages and that is also what all the documentation on the NuGet site is about. Once you realize that NuGet can also be used as a distribution system of packages for your own application, things get more interesting. You can get started developing such thing by adding the NuGet.Core assembly to your project and navigating around with IntelliSense. The whole system is pretty slick and I’m using it in other applications I work on as well.

NuGet has a lot more uses than what can be seen at first sight, there is a whole lot to explore!”


Thank you Kelly for this chat, really appreciated!

Just like OCTGN, if you are working on an open source project you can get an Open Source subscription plan for your project!

Happy packaging!

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!