One of the most requested features for MyGet so far is support for webhooks. We’re happy to announce MyGet webhooks (preview) is available today. Every MyGet feed provides the option to communicate with external services, such as a web server, whenever a specific action occurs on the feed.
Webhooks support is not enabled by default. Since the service is still in preview, you will have to opt-in to this feature by clicking here.
Only feed owners and co-owners can manage webhooks for a feed. Each webhook can be triggered for one or more event types, depending on the implementation. Webhook deliveries can be inspected, including full logs, as well as redelivered in case this is needed.
Give webhooks at try! If you wish to enroll in the MyGet webhooks preview, please click here. For more information, check our documentation website. We’re open for any feedback or feature requests you may have.
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.
12. June 2014 10:46
When you create a MyGet feed, chances are you want to keep the packages up to date. This can be done automatically by enabling auto-update on the package sources for your feed, but that is not always desired. Some people prefer updating individual packages manually, which makes perfect sense: only packages you approved will be available on the feed.
To help detecting package updates, we’re now showing a notification on the package details page whenever any of the configured upstreampackage sources has a newer version available. With just one click, we can update the package and its dependencies.
Give it a try on your MyGet feed!
3. June 2014 05:10
When managing your dependencies using MyGet, it may be important to have a view on which licenses are used on your feeds and in your software projects. Which licenses are your NuGet packages using? Many teams would love to know which (open source) licenses are being used by their teams, so they can be inspected and managed. It feels good to finally tackle one of those items that have been on our backlog for almost two years: we now support this exact scenario!
Note: this feature is only available for paid subscriptions.
From your feed, a new Licenses tab should now be visible showing a report of all licenses used by packages on your feed.
The licenses overview gives you a chart that provides a quick view on licenses in use. The list underneath shows all different licenses used per package identifier. If a package changed license over time, it will be listed twice. To quickly filter the detailed list, simply click one of the colors in the chart: this will show just the packages that have the selected license applied.
Where does license information come from?
Whenever a package is uploaded to your feed, whether from an upstream package source or by using nuget push, MyGet will perform a license analysis on the package. The license is determined as follows:
- If we’ve seen the package’s license URL before, we will assign the same license to the package that is being added.
- If your feed contains a package with the same identifier, we’ll take that package’s license.
- If we haven’t, we’ll download the license URL result and run a full-text analysis on it. We’ve been working on a unique scoring algorithm which compares the text with known OSI licenses out there.
- If the score is too low, we assign the license “Unknown” to the package.
Can I change licenses for a package?
Absolutely! Whenever you have a package where the license analysis was incorrect, or you have a proprietary package which has a unique license name, it is possible to assign it to a package. From the package details page, you can inspect the package license as well as override it.
Editing the license will open a dialog in which you can edit the license. We’ll provide autocompletion on known OSI licenses, but if you have a proprietary license name that can be entered here as well. Once a license has been overriden, new versions of the package will be assigned the overriden license.
We’re eager to hear your feedback on this feature!
Since NuGet 2.8, the NuGet Package Manager Console’s Install-Package command comes with support for specifying the dependency version resolution process using the –DependencyVersion switch. If you have never used it before, what it does is it allows you to specify how NuGet should resolve package dependencies. It can resolve dependencies to the lowest possible version (default behavior), the highest possible version, or the highest minor or patch version.
This feature is useful because it gives you control over how dependencies are resolved. For example, when package A has a dependency on package B >= 2.0 and available versions of package B are: 1.0, 2.1.1, 2.1.2, 2.2.1, 2.2.2, 3.0.1, 3.0.2, the version of package B that will be resolved will be:
- 2.1.1, when DependencyVersion is Lowest
- 2.1.2, when DependencyVersion is HighestPatch
- 2.2.2, when DependencyVersion is HighestMinor
- 3.0.2, when DependencyVersion is Highest
Word of warning: changing the default behaviour may break package dependencies. In theory, only the lowest defined version number is sure to work. If a dependency is specified for packages >=1.0.0, using DependencyVersion Highest would potentially bring in version 7.0.0 which may not work for the package depending on it. Use with caution!
If you are interested in always having the latest versions of a dependency within a given mayor version, the HighestMinor setting will actually do that. This can be done from the Visual Studio Package Manager Console:
This can also be set as a default for all NuGet packages installed by editing the NuGet.config file or using NuGet configuration inheritance:
<add key="DependencyVersion" value="HighestPatch" />
When adding packages from an upstream feed like NuGet.org or a TeamCity server to a MyGet feed, this setting is available as well:
This should greatly help in getting your preferred packages installed instead of having to install and manually update dependency versions to the required version for your project. For more information about the DependencyVersion switch, do check the NuGet documentation.
25. April 2014 04:17
MyGet Enterprise contains everything MyGet has to offer, hosted on a dedicated URL for your team. It comes with an additional management dashboard that can be used to manage everything related to the team such as feeds, users, quota, account policies and so forth. We recently made some additions to this mangement dashboard that make managing a MyGet Enterprise account even more powerful.
When navigating to the management dashboard as an administrator, you will be greeted by a new menu entry: Account. This section allows access to management of:
- Password requirements, such as
- Minimum password length
- Required lowercase characters
- Required uppercase characters
- Required numeric characters
- Required special characters
- Lockout policy
- How many invalid login attempts are allowed? In what timeframe?
- How long should accounts be locked out?
- After how much idle time should users be logged off?
We also added the ability to unlock users from the Users section. This way you can also manually unlock users within your team if required.
Speaking of the Users section… Many teams wanted to have the ability to have an administrator create users insted of waiting for users to register their own account. Users can now be created by clicking the Add a new user button, after which the display name, user name, password and e-mail can be entered. Optionally, a welcome e-mail can be sent to the user as well.
Full documentation on the MyGet Enterprise management dashboard is available as well.
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:
6. March 2014 08:00
It’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!