MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Picking the right dependency version adding packages from NuGet.org

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:

NuGet select dependency version resolution strategy

This can also be set as a default for all NuGet packages installed by editing the NuGet.config file or using NuGet configuration inheritance:

<configuration> <config> <add key="DependencyVersion" value="HighestPatch" /> </config> </configuration>

When adding packages from an upstream feed like NuGet.org or a TeamCity server to a MyGet feed, this setting is available as well:

Specify DependencyVersion switch with MyGet

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.

Happy packaging!

Configuring password policies and account lockout using MyGet Enterprise

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.

Managing account policies for MyGet EnterpriseWhen 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?
  • Session
    • 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.

Happy packaging!

Using MyGet as a OneGet package source

At the Build conference, Microsoft announced the Windows Management Framework 5.0 Preview which includes Windows PowerShell 5.0, updates to the PowerShell ISE, Network Switch Cmdlets and ... OneGet!

What is OneGet?

OneGet a unified package management interface component with a set of managed and native APIs, a set of PowerShell cmdlets, and a WMI provider. The component accepts both Microsoft-provided and 3rd party-provided plugins which extend the functionality for a given package type.

The OneGet team also has a weekly community meeting of which you can see the first introductionary recording below.

As part of this Preview, OneGet is shipping with a prototype plugin compatible with Chocolatey, the so called ChocolateyProvider. This is a prototype implementation of a Chocolatey-compatible package manager that can install existing Chocolatey packages. This is a clear confirmation for the hard work done by the Chocolatey folks, and both systems will continue to evolve together, as Rob Reynolds explains in this post. If you want to follow-up on OneGet, then check out its GitHub repository and follow PSOneGet on Twitter.

Something about a forest and trees...

NuGet, MyGet, Chocolatey, OneGet... what?! People ask questions and occasionally can't see the forest for the trees. Here's a quick recap:

  • NuGet: a solution-level package management tool, used to manage software dependencies within the scope of a solution. It is accompanied by the NuGet Gallery, the home of many if not all .NET open source components.
  • Chocolatey: a system-level package management tool, used to manage software installations on a Windows system. It (currently) leverages PowerShell and NuGet, supports the Web Platform Installer (WebPI), MSI, RubyGems and many more, and is accompanied by the Chocolatey Gallery where you can find many popular software packages. Rob describes Chocolatey as somewhat like "apt-get", but with Windows in mind.
  • MyGet: a hosted NuGet package server where you can create and secure your own feeds. In essence, MyGet is able to host vanilla NuGet feeds, as well as Chocolatey feeds.
  • OneGet: a a unified interface to package management systems (see above)

So what does this mean? How do these package managers play along?

OneGet supports multiple package sources, and as stated earlier, OneGet comes with a ChocolateyProvider. As MyGet also supports Chocolatey feeds, this effectively means that you can register a MyGet feed as a Chocolatey package source in OneGet! The blow diagram is an attempt to illustrate how they relate:

How do OneGet, Chocolatey, NuGet and MyGet play along?

OneGet supports several commands at this stage:

OneGet Preview cmdlets

How can I use a private OneGet package source?

So how can I register a private OneGet package source? Well, let's first see how you can register any package source using the Add-PackageSource cmdlet. Here's what the built-in help currently says:

OneGet Add-PackageSource Help

Note that this is a Preview: help is incomplete and cmdlets might change name, but this should already give you a good idea of what you can do with this cmdlet!

Now, let's register a MyGet feed on which you can host Chocolatey packages:

Register a MyGet feed as a OneGet package source

Did you notice how OneGet asked you to install the NuGet package manager?

That went easy right? That's because that feed was public :) OneGet does not support basic-authentication at this point, nor does it leverage any nuget.config settings you might configure (tried it). However, MyGet just added the possibility to use a "private-by-obscurity" endpoint on private feeds, which should allow you to use private feeds as well. Note: we don't actively promote this, as it requires you to share one of your feed's access tokens. This is a work-around for clients that don't support the basic-auth flow, and we'd prefer to have proper basic-authentication support in OneGet, so fingers crossed!

You can verify the correct registration of your OneGet package source using the following commands:

Get OneGet package sources List available packages on a OneGet package source

Installing a software package from this MyGet feed is straightforward as well:

Install a software package from a specific OneGet feed

This flow allows you to control what packages get distributed through OneGet, avoids the need to publish your internal software to the general public, and still allows you to leverage the great new scenarios that OneGet offers!

As usual, happy packaging! :)

Receive feed activity notifications through RSS

Ever wanted to get notified when a new package is available on your feed? Did you know you can just browse the Packages collection on any NuGet feed?


Obviously, that also works on MyGet feeds, but did you know that ever since we launched MyGet, we had this little RSS endpoint sitting around?


In it's early state it was just exposing your feed's OData Packages collection. However, as we introduced activity logs and started collecting this data to show up in activity streams on the web site, we can now also provide you with a more useful RSS feed.

Wouldn't it be useful if we just gave you your activitylog through RSS? Let's see what it looks like in it's current form:

We think this is pretty useful. This is only a minimum-viable notification system in our opinion and we'd love to get feedback on how we can improve this further to match your needs. So please, don't hesitate to reach out and let your voice be heard! One address: http://myget.uservoice.com.

Besides simply subscribing to the RSS feed, you might want to make the internet work for you.

Our friends at MessageHandler have built something that hooks into our activity streams, allowing you to configure a handler that sends you an email and creates a GitHub issue when a MyGet build fails.

For those using IFTTT (if-this-then-that), we've also created a few recipes (or you can build your own):

Happy Packaging!

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!

Checking NuGet package vulnerabilities with OWASP SafeNuGet

Edit - October 14, 2016 - We have a new, integrated vulnerability scan service.

A couple of days ago, OWASP released a new NuGet package which is able to check known vulnerabilities in NuGet packages. Use of libraries with known vulnerabilities can be an issue for software and components you create: check the excellent whitepaper "The Unfortunate Reality of Insecure Libraries". In the OWASP Top 10 2013, consuming vulnerable packages is listed under A9 Using Known Vulnerable Components.

There is a simple solution to this: by installing one additional package in your projects, automatic checking for known vulnerabilities can be done. The SafeNuGet package contains an MSBuild task which will warn you about this.

A repository with vulnerable packages and the reason for that can be found on the SafeNuGet GitHub project. When running a build which references vulnerable NuGet packages, the warnings list will contain some information about this as well as a link with some explanation:

Checking package vulnerabilities

And of course when such library is built using MyGet Build Services, a warning will also be displayed in the build log:

MyGet build services security scan

It would be great if the build would fail entirely when such package is found, right? Well, that is a simple configuration parameter for the SafeNuGet package. Find the SafeNuGet.targets file and update its contents to:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <UsingTask AssemblyFile="SafeNuGet.dll" TaskName="SafeNuGet.AreNuGetPackagesSafe"  />
  <Target Name="AfterBuild">
    <AreNuGetPackagesSafe ProjectPath="$(MSBuildProjectDirectory)"
         CacheTimeInMinutes="10" DontBreakBuild="false" />
  </Target>
</Project>

Want to make sure known vulnerabilities are shown in your builds? You know the drill:

SafeNuGet

Happy and safe packaging!

Specifying which projects get built with MyGet Build Services

Using MyGet Build Services, you have the opportunity to control exactly how your project gets built. By default, several conventions are used to run builds. MyGet will scan the contents of your Source Control Repository looking for a file which it can work with. In order of precedence, the following files are searched for:

  • Project files (*.csproj, *.vbproj, ...) specified in the build source configuration.
  • MyGet.bat, MyGet.cmd or MyGet.ps1
  • build.bat, build.cmd or build.ps1
  • MyGet.sln
  • Any other *.sln file
  • *.csproj (and *.vbproj, etc)
  • *.nuspec

With the latest deployment of MyGet Build Services, it is now possible to specify which project(s) to build, per build source configuration.

MyGet Specify Project to Build

The projects to build can be C# or VB.NET projects or solutions. Based on the files found, the build process will be slightly different. See the documentation on MyGet Build Services for more information.

Happy packaging!

Migrate away from MSBuild-based NuGet package restore

Back in the days...

NuGet package restore used to be MSBuild-based. You had to explicitly enable it using the context menu on a Visual Studio solution: right-click the solution and select Enable NuGet Package Restore. In fact, if you go to the NuGet docs, you'll see that this scenario is still fully documented. A quick search for "package restore" will throw this old scenario "in your face", as it is the first hit in the search results.

First hit in search results when looking for Package Restore on the NuGet docs

To be fair, the page does highlight that there's a new way of doing this. But many people don't read. At best some look at the pictures. That's why I won't even include a screenshot of that page, as it is full of project setup details that no one should ever go through again. Instead, I'll give you a clear picture of what you should not do :)

Don't do this!

You're doing it wrong!

I can't stress it enough. I'm a huge proponent of NuGet package restore! But if you follow this workflow, then please do it right! (and design for failure, obviously).

The MSBuild-based NuGet package restore has issues. For one: it's MSBuild-based. This means that anything that happens during package restore is run within the MSBuild process, which is particularly annoying for packages that want to modify project files and inject MSBuild targets (as these aren't picked up until the next run).

The moment you manually enable NuGet package restore through the context menu, you're actually installing a few NuGet packages: NuGet.Build, which depends on NuGet.Commandline. The nuget.exe along with a nuget.config and a nuget.targets file are created within a .nuget folder, and all projects that have NuGet package references will be modified to import the NuGet.targets file. The nuget.targets file ensures that nuget.exe is invoked during builds (as in: not before builds!).

The right way

All you need to do is to make sure that your Visual Studio options allow NuGet to download any missing packages in a pre-build phase (note: even before MSBuild compilation starts!). I'm not going to rephrase step-by-step what you should do as David Ebbo already has a great post explaining all of this!

Ensure NuGet is allowed to download missing packages

If you're cloning a new project that did not commit any NuGet packages (and is not using the old MSBuild-based restore), then it just works!

Migrating from the old way

If you still have a .nuget folder in your repository, then please migrate away from it! Think about all those adorable kittens...

Did you know this has been documented on the NuGet Docs all along?! Follow this how-to and save yourself and everyone using your codebase some trouble and follow it step-by-step.

But... my precious (build server)

Here you go: set this environment variable to true and be done with it.

EnableNuGetPackageRestore=true

The following tools support the new automatic package restore out-of-the-box and Just Work™!

The next list of tools requires some minor modifications to the build process:

  • Visual Studio Online / Team Foundation Server (how-to)
  • TeamCity (how-to)

Note that you don't need to worry about development machines! As long as you all have the latest NuGet Visual Studio extension installed.

Upgrading your NuGet extension is generally a good idea anyway, as there are lots of improvements in the latest versions!

Going forward

Here's what I'd love to see happen going forward:

  • The NuGet Docs should by default show the new non-MSBuild-based package restore instructions. There are close to none, but this should be thrown in your face when looking for it.
  • Migration instructions should be clearly linked to.
  • The old MSBuild-based instructions should be archived, perhaps even removed.
  • The context menu-item to manually enable NuGet package restore (MSBuild-based) should be completely removed from the extension. I don't see any reason to keep it. Do you? If you do, please comment on this CodePlex issue, if you agree, then vote for it :)
  • Preferably, the next NuGet Visual Studio extension detects you are using the "old" restore option when you open a solution, and asks you to migrate/upgrade to the new way. Ideally, this removes the targets and import statements, and custom package sources and credentials are taken into account if they are in the nuget.config file.

I'm happy to take on an issue or send PR's for any of the above, but some of the bullet-points seem too big to me to be taken in as a PR.

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!