We are happy to announce that MyGet partnered with Microsoft to be included in the Microsoft Azure Store. This is our second partnership with them, since we also integrate with Visual Studio Online. The Microsoft Azure Cloud is widely used to build and deliver applications to end-users. Developing these applications could greatly benefit from using a package management solution to streamline development, and that’s where MyGet comes in.
Having MyGet available in the Microsoft Azure Store allows developers and team leads to create MyGet accounts for themselves or their team members, whether free or one of the paid plans. There are no separate bills to be paid: MyGet will be part of the monthly account statement or Enterprise Agreement.
If you are a Microsoft Azure customer, here’s how to create a new MyGet account:
- Go to the Microsoft Azure Management Portal
- In the bottom toolbar, click New and select Store
- In the Choose an Add-on dialog, select MyGet and click next
- In the Personalize Add-on dialog select the MyGet plan you want to sign up for.
- If you want to create one (or more) paid subscriptions, you can use the promotional code STORELAUNCH, which will give you a 25% discount during the first 6 months of the subscription (code valid until end of August, 2014).
- Once the subscription is created, click Manage in the bottom toolbar and pick the username and password you wish to use for your MyGet subscription.
If you are an existing MyGet user and would like to make use of the Microsoft Azure Store integrated billing, contact support and we will make it happen!
We’ve supported the “Push upstream” workflow for quite a while now. This workflow allows you to promote packages from one feed to another, ideal when you are pushing prerelease packages on one feed and pushing them as stable packages to another feed after testing them.’
So far, it has been only possible to push individual packages upstream, or all “latest” packages. We realized this was painful for one scenario: if you’re usign Build Services, it may be handy to be able to push just the packages generated by a specific build. And that is exactly what we’ve added now!
When expanding a build’s packages, a new menu entry Push upstream…is now available to push the packages generated by a build to another feed. This should greatly improve usability for this scenario.
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 :)
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:
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:
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.
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
Setting default package sources during build
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:
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.
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.
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.
28. February 2014 07:31
MyGet 1.9 was released on February 27, 2014. We will be blogging about new features in the next days and weeks.
MyGet Build Services
- 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, ...
We recently shed a light on how you can easily use additional build tools on MyGet Build Services. However, there is more. A lot more!
We always say how much we love our users and this blog post is yet another illustration why we do. One of our users, Peter Rekdal Sunde, created an awesome PowerShell utility pack to make it even easier to customize your MyGet Build Services experience. The result is a complete build suite for creating NuGet packages and interacting with the MyGet Build Services environment. The scripts not only work on MyGet but also on your local development computer (you do need to have msysgit installed though). The entire code base was generously opensourced (MIT license) and is available on GitHub: https://github.com/peters/myget.
How does it work?
Simply include the myget.include.ps1 script in your build.ps1 on MyGet and use the provided functions.
Where do I begin?
To illustrate its purpose, we provide you a glimpse at some of the functionality provided by these scripts:
Build agent communication
- MyGet-Write-Diagnostic - writes a diagnostic message to the standard output
- MyGet-Build-Success - report build success
- MyGet-Die - report build failure
NuGet utility functions
- MyGet-NuGetExe-Path - path to NuGet.exe
- MyGet-NuGet-Get-PackagesPath - returns the value of the repositoryPath attribute in nuget.config for a given project folder
- MyGet-Build-Bootstrap - starts a build (including NuGet package restore)
- MyGet-Build-Solution - starts a build of a solution file
- MyGet-Build-Project - starts a build of a project file
- MyGet-Build-Nupkg - creates a NuGet package based on a specified .nuspec file. The .nuspec can contain additional replacement tokens, taking benefit from some of the variables provided by default by MyGet Build Services. More information at https://github.com/peters/myget#nuspec-substitutions.
- MyGet-TestRunner-Nunit - invoke NUnit
- MyGet-TestRunner-Xunit - invoke XUnit
We recommend you to check out the readme and the samples for a detailed view of what's available though. Especially the test runner support is really nice, just check the below example!
Thank you Peter!
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:
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.
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.
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.