MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

MyGet Documentation site redesigned

When we first launched the MyGet Documentation site, we decided to fork the NuGet documentation site and apply our own colors and content to it. After our website redesign a few months ago, we felt it was time to work on our documentation site’s design, too.

Documentation on how to use MyGet

The front page looks completely different. We decided to put a search engine central, as well as some popular articles that can help you get started.

One of the things we want to encourage everyone to do is comment on documentation: explain how you did something, ask questions and get help. If we see there are some things that are not completely clear from these comments, we’ll work on additional documentation there. Therefore, every article now gets a section where you can add your comments.

Add comments to MyGet documentation

Not that we are lazy, but if you feel you can do a better job at an article, spot a typo or want to add something, every article features a direct link to our GitHub repository where you can send us a pull request with changes. And that’s not work you’re doing for free: for every accepted Pull Request, you get a free one month extension of your current subscription.

image

Happy packaging!

Where does this package come from?

Ever wondered where a package comes from, or if it exists on any of your package sources? Our latest deployment features a tiny little gem on the package details page which gives us that information:

Package found on

MyGet will query all configured package sources and check if the package exists on there. If it does, a link to it will be displayed in the package details page.

Happy packaging!

Which packages are added to a feed during build?

With MyGet Build Services, it is very easy to create NuGet packages from source control. Link a GitHub, BitBucket or CodePlex project to your MyGet feed and we’ll take care of building it and publishing generated packages to that feed. But which packages are added to your feed?

By default, MyGet will add all NuGet packages generated during build to your feed, as long as they are created in a folder named other than packages. The reason for this is that the packages folder is reserved by NuGet itself and may contain packages that were used during the build process and are not necessarily to be added to your feed. When creating a batch-based build, make sure to generate packages in a folder not named packages. A good example folder name could be output.

How to be selective about this? Is it possible to specify which packages are added to your feed? Well yes! To override the default behaviour, a series of wildcard matches can be specified in the build source configuration. When omitted, all packages generated during build will be pushed to your feed. When specified, only packages matching any of the specified package names or wildcards will be pushed to your feed.

image

In the above example, all package names matching Google*.nupkg or Newtonsoft* will be added to your feed.

Happy packaging!

Enhancements to MyGet Gallery for Enterprise subscriptions

All MyGet Enterprise subscriptions feature a complete “copy” of MyGet, tailored to your organization’s development team. A custom URL provides access to private repositories used by your team. But what if you want to make a specific feed available to the general audience? And how can private feeds within the organization be easily discovered by team members?

The answer to these two questions? The MyGet Gallery. It serves as the Golden Pages for your team’s NuGet feeds. Through the feed settings, a feed can be listed in the gallery, complete with a readme and icon.

Adding a feed to the gallery

Only public and community feeds will be shown in the public MyGet Gallery. Feeds that are public within your team will only be shown in the MyGet Gallery for authenticated users. This makes the MyGet Gallery a great place to discover feeds! Your customers can browse the MyGet Gallery and see which feeds they can use. Team members will see feeds that are only available within the organization and can have a look, too.

MyGet Gallery

And if you want to disable the MyGet Gallery? Simply use the administration dashboard to do so.

Disable gallery

Happy packaging!

Build Status Badges

With MyGet Build Services, you can embed a status image for a build into any web page out there, including your project’s README file or documentation. Your users will be immediately updated about the status of the last build performed. Here’s an example badge for a successful build:

MyGet Build Services Status Badge

Badges will be shown for pending builds (queued or building) as well as successful and failed builds.

The URL for a build badge can be obtained through the Build Services configuration:


It can then be used in HTML, for example with a hyperlink to your feed on the MyGet Gallery:

<a href="https://www.myget.org/gallery/googleanalyticstracker"><img alt="GoogleAnalyticsTracker Nightly Build Status" src="https://www.myget.org/BuildSource/Badge/googleanalyticstracker?identifier=479ff619-28f2-47c0-9574-2774ed0cd855" /></a>

You can do the same in Markdown:

[![GoogleAnalyticsTracker Nightly Build Status](https://www.myget.org/BuildSource/Badge/googleanalyticstracker?identifier=479ff619-28f2-47c0-9574-2774ed0cd855)](https://www.myget.org/gallery/googleanalyticstracker)

Of course, you can also use it in any other markup language that supports embedding images.

Happy packaging!

Publishing packages to NuGet.org during build

Ever wanted to push a package to NuGet.org or another feed during a build on MyGet Build Services? Affraid of checking in the API key to source control just to be able to do that? Well here’s a little trick that will help you do that without spilling secrets.

When we implemented support for NuGet Package Restore, we’ve also added support for transfering package source credentials to the build server in a safe way. From the Package Sources tab on your feed, you can use the Add package source button to specify all details about a feed that should be available during build, both for consuming and pushing packages. You can add any feed you want: a Chocolatey feed, a TeamCity feed or another MyGet feed.

NuGet Push in MyGet build

After specifying an API key through MyGet, you can simply push packages during build, from your build.bat. Let’s push all packages in the build’s release folder to NuGet.org:

nuget push release/*

Prefer pushing MyPackage 1.0 to another feed? Add it as a package source in MyGet, specify the API key and push from build.bat:

nuget push MyPackage.1.0.nupkg -Source http://other-feed

Note that the packages generated during build will also be added to your MyGet feed.

Happy packaging!

GitHub Releases and MyGet Build Services

During the summer, GitHub added a great feature for many projects: releases. Projects on GitHub can create a release and label sources, add binaries and release notes. Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.

Since MyGet Build Services supports labeling and we can label sources when pushing packages upstream, GitHub Releases make a great combination with MyGet! Let’s see.

Labeling Sources from MyGet

When enabled in the build source configuration on MyGet, source code can be labeled with the build number. This can be done for successful builds only (recommended) as well as for failed builds.

Label Sources during Build and make it a GitHub release

It is also possible to base tags for GitHub Releases on having a fresh package pushed to, say, NuGet.org. This can be done while pushing packages upstream or “promoting” them. A dialog will provide you with additional options, e.g. configure the package version to be used upstream, as well as the option to label the sources for packages originating from MyGet Build Services.

GitHub release when pushing to NuGet.org

Releasing through GitHub

Regardless of the approach taken for creating a label, all that is left now is creating the release on GitHub. Since either the build process or the package promotion process have created the label already, all that GitHub requires is a set of release notes and a description for the release.

Integrating GitHub Releases and MyGet

Pretty sweet, no? Let us know your thoughts through the comments below or in our forums!

Happy packaging and shipping!

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!

Using additional tools in the build process

Out of the box, MyGet Build Services supports building projects that depend on various SDK's and/or test runners. A full list of supported project types and SDK's at your disposal is available on our docs.

However, sometimes you run into a missing tool or SDK you absolutely need to compile your projects. Or perhaps you need a different version than the one available by default. If that's the case, you have two options:

  • Download the tools you need and commit them to your own repository
  • Use the brand new MyGet Build Tools repository on GitHub as a submodule to your repository

The first option is likely what you're doing today and allows you to cherry-pick the required tools without polluting your build with tools you don't need, making the build process faster.

The second option will bring down the tools from this repository during a build while they are technically not in your own GitHub repository. It currently contains the following tools:

  • NuGet 2.5, 2.6, 2.7, 2.7.1
  • NUnit 2.6.2
  • XUnit 1.9.6
  • curl

To add a submodule, run the following from your repository root (make sure you use the https endpoint):

git submodule add https://github.com/myget/BuildTools.git myget

From then on, you can use the tools from the myget/tools folder in your builds. For example, NuGet 2.5 can be used by calling myget/tools/nuget/2.5/nuget.exe.

Happy Packaging!

Making your life easier with multiple access tokens

What if you are using your API key on your TeamCity server and several other locations and for some reason you have to reset that API key? Major headache? Not anymore: from now on, MyGet supports multiple access tokens.

Since MyGet day one, we’ve had support for two credentials linked to your account. The primary API key could be used when publishing packages with NuGet.exe or NuGet Package Explorer while your username and password were useful when consuming private feeds from Visual Studio or a build server.

Additional access tokens can be generated from your profile page. The primary API key can be regenerated and new tokens can be easily created or revoked. Access tokens can be given a short description: this will help keeping track of where you used the access token and revoke it if necessary.

Access tokens can be used for all authentication purposes. They can be used when pushing to your MyGet feed or as an alternate password when authenticating against a private feed or SymbolSource.org.

Go ahead and separate the credentials you use personally, on the build server or in other software. Access tokens can be created and revoked at any time.

image

Happy packaging!