MyGet Blog

Package management made easier

NAVIGATION - SEARCH

NuGet Dependency Management with Drone Delivery

Using MyGet just became easier. We are proud to announce a new feature (in preview) which brings a better and bolder way of consuming NuGet packages from your feed! Next to using Visual Studio or the NuGet command line tool to have packages delivered to your project, it is now possible to have packages delivered by drones using the new Drone Delivery feature.

Many established companies, as well as startups, are experimenting with drones for their services. MyGet will be the first to offer dependency management using this approach. And for good reasons: the Drone Delivery feature will make package restore a breeze even if you lose your Internet connection.

Here’s an overview of how Drone Delivery works:

How drone delivery works

The new Drone Delivery feature will surface in many places throughout the MyGet website, for example on package details pages and in the MyGet Gallery. It is also possible to consume all packages from a feed using Drone Delivery:

Drone Delivery of an entire feed

We're really excited about this feature and will be adding additional capabilities in the future. We are thinking about Google Glass apps and Oculus VR support to enable tracking package delivery in real time.

More information on this new feature can be found in our documentation. If you want the preview of Drone Delivery enabled for your account, let us know.

Happy packaging!

Setting default package sources during build

MyGet gives you the option to specify one or more package sources for a feed. Package sources for a feed are also available during every build on MyGet Build Services. This can be really useful!

  • An additional package source is needed during build. MyGet will make the package source available during build if it has been added to the feed's package sources.
  • 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.
  • The API key for a package source is also transferred to the build server. This means during a build, you can call into nuget.exe push and push packages to configured package sources.
  • You want to make use of nuget.exe push in a build script without having to specify the -Source parameter.
Setting default package sources during build

The NuGet.config on our build machines is configured using NuGet's defaults, enriched with all package sources configured for a feed. Based on these defaults, the following conventions are active:

  • The default package source is set to (Aggregate Source), meaning all feeds will be queried for packages in the order defined in the feed's package sources.
  • The default push source (when using nuget push without the -Source parameter) is NuGet.org.

Both of these conventions can be overridden by editing the build source configuration:

Setting package sources used during a build with NuGet

Happy packaging!

Join the Global Windows Azure Bootcamp 2014

Global Windows Azure BootcampIt’s no secret that MyGet is running on top of the Windows Azure cloud platform. Because we love it and want to get as many people to learn about it, we’re participating again in this year’s Global Windows Azure Bootcamp.

In April of 2013 the first Global Windows Azure Bootcamp was held at more than 90 locations around the globe. This year’s bootcamp will again offer a one day deep dive class to help thousands of people get up to speed on developing Cloud Computing Applications for Windows Azure. In addition to this great learning opportunity there will be a hands on lab in which everyone can participate. A huge global compute farm will be created by attendees to perform diabetes research!

If you want to learn about Windows Azure or help in diabetes research, find a location near you and join this massive event on Saturday, March 29, 2014. MyGet is giving away a free 2-month Starter subscription to every attendee, and other sponsors are offering swag and licenses as well!

Happy packaging in the cloud!

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!

Release notes for MyGet 1.9

MyGet 1.9 was released on February 27, 2014. We will be blogging about new features in the next days and weeks.

Features

MyGet

MyGet Enterprise

MyGet Build Services

Bug Fixes

  • Packages downloaded through the browser now have a .nupkg file extension
  • NuGet Package Explorer 2.8 publishing works again
  • Package restore with proxied feeds now works on feeds larger than 100 packages
  • Load time of activity feeds has been improved
  • Push upstream now works with private feeds

Next to all these, we have done a tremendous effort on our back-end: upgrade to the latest Windows Azure SDK and switch to JSON-based traffic to our storage accounts, a new queuing framework which increases back-end messaging throughput, ...

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!

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!

Package not found during package restore

When working with your own feed, whether private or public, chances are you want to consume more than just that feed. We see many people using their MyGet feed and the NuGet.org feed simultaneously. Sometimes, an interesting error occurs during package restore.

Unable to find version xxxx of package yyyy

That’s not funny! You know that the package is on the feed as you’ve installed it from there in the first place! The reason this happens is because the NuGet command line, the NuGet Visual Studio Extension and the NuGet PowerShell Console all have a configuration option specifying which package source to install from. When this setting is changed to one specific feed, other feeds will be ignored and the error above will be shown during package restore.

The solution is very simple: you can set the active package source to aggregate in Visual Studio, or simply configure NuGet to always use the aggregate package source for the current project. NuGet has an inheritance system for NuGet.config files, where the NuGet.config file closest to the solution file gets the last say. So in short, if you add the following NuGet.config file next to the solution file for your project, you should be fine:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
</configuration>

We can take this one step further and instead of configuring your MyGet feed globally for your system (and requiring other devs on your team to do the same), why not distribute a NuGet.config along with the sources?

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
    <add key="MyGet" value="https://www.myget.org/F/chcuknorris/" />
  </packageSources>
  <disabledPackageSources />
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
</configuration>

This really makes working with multiple feeds a breeze. But we can go even further and use only MyGet, proxying packages from NuGet.org along the way. For more info on how that works, check the documentation on upstream package sources.

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!