MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Modify NuGet package description and release notes before pushing upstream

Ever enjoyed watching your builds go green to find out that the packages created had a typo in the description? Or you simply forgot to add release notes? Very annoying if you simply want to push your packages out there!

This annoyance triggered one of our dear customers to send us a feature request: "What if I could modify these fields before I hit the Push button?" Well, we thought that was indeed a great idea, so we implemented it, whilst we also gave the UI a little more love :-)


If you click the Edit button next to each package, you'll now have the ability to modify the pre-release tag, the package description, and the package release notes. With a click of a button, you can also apply the release notes to all packages listed in the dialog. 


And to finish it off, we support markdown in the release notes. Packages that have release notes which contain markdown will be rendered nicely on the package details page.

Happy Packaging!

Black Friday Sales - 30% discount on MyGet Starter and Professional

Thank you! Black Friday dealsWhile in Europe we don’t have holidays this week, we do want to share the tradition of Thanksgiving. MyGet could have never grown into what it is today without you. We'd like to thank you by having a sale on our Starter and Professional plans!

Starter and Professional Subscriptions of 6 months get a 15% discount. If you decide to stay with us for a full year, we’ll give you 30% off!

Interested? Sign in to your MyGet account and create a new subscription or extend your existing one.

Since today is “Black Friday” and right after the weekend is “Cyber Monday”, we’re keeping this sale available until Tuesday December 2nd, 2014. This gives ample opportunity to purchase a MyGet subscription at a discounted rate.

Happy packaging!

PS: Give our new features a try, too. We have service messages support, more web hooks and a load of other things!

Build Services supports Service Messages

Service messages for MyGetWe’ve just deployed support for service messages in MyGet Build Services. With them, you can interact with our build agent by simply writing a message to the build output. This makes it easy to work with them from any build framework used, be it a simple batch file, PSAKE, MSBuild or others.

But what can you do with them? Why are they useful? There are a couple of situations that come to mind:

A service message looks like this: ##myget[buildNumber '1.0.0-beta1']. We also support a subset of TeamCity service messages. This makes your builds more portable between build systems and gives you more control of the build process. More information is available from our documentation.

Happy building, and happy packaging!

MyGet 1.9.5 Release Notes

MyGet 1.9.5 was released on November 18, 2014.

Major Features

It's been a while since we tagged another MyGet release, but here we are, 9 months after tagging v1.9.0. We constantly ship and deploy improvements to our service so this v1.9.5 basically aggregates everything we've done since then, combined into a single milestone. This release contains many exciting new features. We'd love to hear from you so please send us your feedback

MyGet

MyGet Enterprise

MyGet Build Services

Minor Tweaks and Bug Fixes

  • Build Services: Builds now fail immediately for feeds that return a 4XX or 5XX status code
  • Build Services: No longer ignore *Test*.nuspec files when packaging
  • Build Services: Assembly Version Patching no longer fails to process files that contain Visual Studio regions
  • Build Services: Delete web hook at GitHub / VSO when build source is deleted
  • API: nuget delete is no longer case-sensitive on package ID
  • Cloning gallery feeds now unpublishes the cloned feed from the gallery
  • Allow updating the description of access tokens
  • Support page - Ability to select the (own) feed related to the support request, which helps us provide even faster support! ;)

In addition, this release also contains a lot of performance fixes, and we continue to work hard on improving your overall MyGet experience. If you feel strong about a missing feature or have an idea for further improvement, please let us know! We build this for you!

Happy packaging!

MyGet supports Chocolatey

Chocolatey is something you need if you've ever installed, upgraded, or removed software on Windows. It is an existing, proven, almost 4 year old project. For those familiar with *nix package managers, it is a binary package manager, sort of like yum or apt-get, but for Windows. 

Here's how the team describes the tool on their Kickstarter campaign:

Chocolatey is a tool that automates all the mundane getting and installing software work for you. You just select what you want installed and within a few minutes, Chocolatey has downloaded and installed (or upgraded) that software without need for further input from you. So while Chocolatey does the hard work, you can go get some coffee. Or sleep. Or do other more important things. 

You probably start to see why we like Chocolatey!

Chocolatey has been part of the NuGet ecosystem since forever, and we are happy Chocolatey users ourselves. From the very first beta of MyGet's package sources functionality, we have had built-in support for ChocolateyIn fact: if you're using MyGet Build Services, then you are already using Chocolatey! That's right: all the tools mentioned in our Build Services docs are provisioned on our build agents using Chocolatey!

We also know some of our users are using MyGet to host their own Chocolatey repository, which in turn is just another NuGet feed. It just serves Chocolatey packages instead.

It goes without saying that we are huge fans of the Chocolatey project and we really want to encourage and support the Chocolatey team to take the project to the next level. If you're like us and love Chocolatey, we'd like to invite you to join us in backing the Chocolatey Kickstarter project! MyGet has pledged $750 to help move the project from experiment to experience.


Chocolatey has proven to be a huge time saver and invaluable tool for us, and if you feel the same, the least you can do is to get yourself a nice box of chocolates ;-)

Let's get Chocolatey!

MyGet feeds now support Target Framework Filtering

On October 1st, the NuGet team enabled Target Framework Filtering in NuGet.org's Search API. We're happy to announce we've just flipped the switch in our back-end to enable this on MyGet feeds as well! Ever since version 2.1, the NuGet clients have been sending the consuming project's target framework in the search requests. Everyone who's using NuGet 2.1 or above is going to benefit from this server-side optimization.

What does this mean for you as a package consumer?

Since NuGet will now be filtering package search results by target framework, in a nutshell, you should no longer see this dialog when installing packages:

More details about this feature can be found on the NuGet blog.

I'm using upstream package sources. Does anything change?

Yes and no. Upstream package sources that support target framework filtering, like NuGet.org and MyGet.org, may return different (but better) results from what was returned previously. For other package sources, we will return search results the way we did before.

If the clients were sending this information to the server since v2.1, what took you so long?

We want MyGet feeds to be fully compatible with the NuGet API that lives at www.nuget.org. This means we want MyGet to provide a consistent behavior from a user/client perspective.

Happy packaging!

Notifications let you know when a package is updated

Call it human nature, but whenever an update to a software package is available we want to know about it and install it immediately. We do this with our computer, phone and even our NuGet packages. For good reason! The packages we depend upon may be updated because of bug or security fixes and even new features we want to make use of.

MyGet already supported automatically updating NuGet packages from upstream package sources, however we felt that this might not always be the best solution for all scenarios. We’ve now made it possible to receive e-mail notifications about package updates instead, allowing you to decide manually if you want to upgrade or not.

Update notifications per e-mail

E-mail notifications can be enabled from your feed’s Package Sources settings, editing the upstream package source configuring which actions should be performed and when.

NuGet update notifications

We will send you an e-mail (or perform an automatic update, or both) at the chosen interval. This helps you keep up-to-date and allows for an easy update of the package: after clicking a link in the e-mail, MyGet will show what the latest available version is and offers a one-click install.

Latest available NuGet package version

Happy packaging!

Configure a feed’s Report Abuse URL

Ever wondered where the “Report Abuse” link in Visual Studio navigated to? Or where it comes from?

Report Abuse URL

This link is available for every package, and on MyGet feeds, it will typically point to a dummy URL. The reason for that is it’s your feed, and you are the one who should respond to any messages that come in through it. But with a dummy URL, that obviously does not work… So we made it configurable! From your feed’s Package Settings tab, simply enter the URL Visual Studio should navigate to when clicked.

Configure Report Abuse link

This should make it easier to gather feedback on packages hosted on your feed.

Happy packaging!

Package mirroring is now enabled by default

Any service can experience a brief moment of downtime. This is also true for any upstream package source you configure in MyGet. That's why we have the package mirroring feature: when uploading or adding a package to your feed, the added package (and its dependencies) are stored into MyGet's own storage system and they remain available in the event of an upstream service outage.

This package mirroring checkbox used to be disabled by default. Why? Because we wanted to save on storage costs. You might think we were being cheap here, but today we are hosting over 50Gb of packages and serving many of them multiple times a day! In the early days of MyGet, it made sense to simply reference the packages from eg. nuget.org and redirect you to the package URL upstream. This has saved us quite some storage, bandwidth and backup costs whilst bootstrapping (you know the Free plan isn't free for us, right?).

However, as we are maturing, we also gain new insights in how you are using MyGet so we can more effectively reduce friction in the way you work with packages. We measured that 95% of our users are mirroring their packages, so we are now reversing the logic for it. As of today, the checkbox will be checked by default!

A popular question we get is: why aren't you hosting an entire mirror of nuget.org? Answer: this is another one of those backlog items that has been sitting around for years, and we believe NuGet API v3 will greatly facilitate such scenario. One day :)

Happy packaging!

Announcing Visual Studio Online integration

We are really excited to announce that as of today, MyGet enables new scenarios for all users of Visual Studio Online! Microsoft just announced Visual Studio Online Extensions at TechEd, so we can finally disclose these new scenarios and toggle the feature-switch for all of you.

In short, these are the new scenarios we've just enabled for you:


New to MyGet? Interested in using the Visual Studio Online integration? Why not make use of our TechEd 2014 offer that gives you a complimentary 2-month Starter plan!

New Scenario: Serve NuGet packages from a Visual Studio Online drop location

Having a VSO Build Definition creating NuGet packages but having trouble consuming those? You can now very easily create a MyGet feed and serve those NuGet packages by having us fetching them from your Drop Location! Optionally, we can post notifications to your VSO Team Room so your team gets informed about new package availability as the result of your automated builds.

Package sources could be considered as upstream repositories for your MyGet feed, which is how you can look at the VSO Build Drop Location. The following simplified diagram provides a schematic overview of this new integration scenario.


All you need to do to make us of this integration is to add a new package source to your MyGet feed:

  1. Go to your feed's settings and select the Package Sources tab. Select Visual Studio Online build definition from the Add package source button.

  2. Provide your Visual Studio Online account name in the dialog that appears and click Continue.

  3. Select the Team Project and Build Definition to add as the package source for your feed. Optionally, select the Team Room in which to post notifications. Click the Add button to complete the configuration of the new package source.

  4. The new VSO package source has been added to your feed's package sources, and newly built NuGet packages will be fetched from your Drop Location automatically and pushed to the MyGet feed.

New Scenario: Add a VSO Git repository as a Build Source for a MyGet feed

This is the same scenario we already support today for GitHub, BitBucket and Codeplex: you can now register MyGet Build Services as a post-commit hook to your VSO Git repositories. We are happy to provide an integrated VSO experience from within MyGet, but even happier to also have a MyGet service hook available within the VSO user interface! Whether you use the VSO user interface or MyGet web site, you can enable this scenario from within both.

Build sources are a way to express links between MyGet Build Services and your source repositories, whether on GitHub, BitBucket, Codeplex or now also on Visual Studio Online. The following simplified diagram provides a schematic overview of this new integration scenario.

Note: we currently only support Git repositories, TFVC support is on the roadmap.


Here's a step-by-step guide on how to register a VSO Git repository within MyGet Build Services.

  1. Go to your feed's settings and select the Build Services tab. Select from Visual Studio Online (git only) from the Add build source… button.

  2. Provide your Visual Studio Online account name in the dialog that appears and click Continue.

  3. Select the desired build source to link and optionally enable notifications in a specific Team Room. Click the Add button to complete the configuration of the new Build Source.

  4. The new VSO build source has been added to your feed's build sources, and a post-commit service hook has been registered within VSO. When pushing to your VSO Git repository, a new MyGet build is going to be triggered and will produce your NuGet packages and push them to your feed.

    If you look at your Visual Studio Online Administration dashboard and browse your Team Project's Service Hooks, you'll see a newly registered web hook listening for the Code is pushed event.

New Scenario: Connect an existing MyGet Build Source to Visual Studio Online

Alternatively, you can also setup MyGet integration from within Visual Studio Online. This is useful if you already have an existing MyGet Build Source pointing to your VSO Git repository and triggered it manually up until now. You should be glad to hear you can now connect these and automate that.

  1. Go to your VSO Team Project Administration dashboard and select the Service Hooks tab.
  2. Click the Add Service Hook button

  3. Within the New Service Hooks Subscription dialog, select the MyGet service and click the Next button.

  4. Select the Code is pushed event type and the desired Repository and Branch settings. Click Next to continue.

  5. Select the Trigger a MyGet build action and provide the target Feed name and Build Source Identifier.

    You can find the Build Source identifier in your MyGet feed settings > Build Sources, as highlighted below:

  6. Click Test if you want to test this service hook first, or click Finish to complete the wizard. The new service hook is now listed as shown below:

We aim to please

We hope you are happy with this brand new VSO support and will put it to good use! We'd also like to express our gratitude to the Microsoft VSO team for enabling this type of extensibility as well as guiding us through this integration effort. A smooth, integrated user experience to reduce development friction is one of our main goals, and we hope these scenarios will prove to be a great help.

Feel free to send us your feedback or feature requests!

Happy packaging!