MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Build services: you decide if symbols are pushed or not

By default, when MyGet Build Services creates a build and produces packages, symbols packages (if any) are pushed to SymbolSource.org. In some scenarios, it may make sense to not push symbols packages, for example when creating early versions of a package or during prerelease phases.

Since our latest release, it’s now possible to change this default behavior. When creating or editing a build source, the Push symbols to symbol server option specifies if symbols should be pushed or not.

Configure symbol server behaviour in build services

Happy packaging!

Automatically trigger a MyGet build using an HTTP POST hook

In addition to manually triggering a build within MyGet, it’s also possible to automatically trigger a build every time code is committed to your source control repository, by making use of HTTP POST hooks.

Once you have fully configured a build source for your MyGet feed, you will be able to manually trigger a build whenever you like. However, if you are trying to adopt the Continuous Integration Software Development Practice, then automatically triggering a MyGet Build whenever you commit some code to source control is one of the first steps in doing this.

The HTTP POST hook URL is a mechanism to allow your Source Code Repository to notify MyGet Build Services (via an HTTP POST to the given URL) when a commit has occurred. As soon as this has happened, a new build will automatically be triggered.

MyGet user gep13 has written a detailed tutorial on working with Build Services and HTTP POST hooks on our documentation website.

Happy packaging!

New documentation site available

We’re proud to have our new documentation site online! This new documentation site can be found at docs.myget.org and will host our FAQ, articles around specific features, reference documentation and so on.

Our documentation is open source and accepting pull requests! To contribute to the docs, just clone our repository and work on the Markdown files in the Docs folder. For more details on the process, read our detailed instructions.

For each accepted Pull Request that closes an issue, you can claim a free one month extension of your current plan. If you're on the free plan you can claim a voucher for a free month on the Starter plan.

Special thanks goes out to gep13, an enthusiast MyGet user who has already contributed several documentation pages.

New documentation website

 

 

 

 

Happy packaging!

MyGet Build Services - Package Versioning Explained

At MyGet, we do everything possible to reduce friction. It's in our DNA! Package versioning is currently the biggest roadblock you'll encounter when setting up a solution to automate package creation.

Versioning semantics

A NuGet package is uniquely identified by its package identifier and its version. This implicit requirement is often overlooked upfront and requires some thinking to define a proper versioning strategy. Luckily for us, some smart people already came up with something called Semantic Versioning (SemVer). We strongly believe in SemVer's pragmatic approach towards API versioning and the benefits that come with it.

Even though NuGet does not fully support the entire specification yet (the SemVer specification is still RC), it already has some features that allow you to benefit from using SemVer. An example of that is the Update-Package -Safe command option, which allows you to update your consumed packages to the latest safe package version: updates are constrained to the same Major and Minor package version. The only drawback of this feature is that you have to count on a safe versioning scheme applied by the package author. This is not guaranteed on the NuGet Gallery.

Build Source Configuration

If you set up MyGet Build Services for your feed, you'll get automatically created packages pushed to your feed. This implies automatic versioning. We've added some new capabilities to our Build Services in our recent MyGet v1.6 release. For one, we've added a UI to define the versioning scheme to be used.

You are in control

The biggest improvement is the fact that the build source now remembers the build counter for you, so you don't have to deal with maintaining a version.txt file or anything similar in your source repository. Of course, if you really want to, you still can: we're removing friction, not features! The build counter can easily be reset using the reset link. Similar to what popular build servers do (and any decent build server should do), you'll be able to define a versioning scheme using a placeholder for the build counter. You've now gained more control over the versioning "magic" we applied before.

In addition, you can gain full control by hooking into the build process. MyGet Build Services scans for the following source artifacts (in order of precedence):

If you provide your own build.bat script or MyGet.sln, you specifically instruct MyGet Build Services how to act on your sources. This also means you'll need to take care of versioning yourself. That's why we provide you with the following set of parameters so you can benefit from using the versioning scheme you already defined, as well as the build-counter attached to your build source. Note that these environment variables are read-only and are reset to the initial values at the start of the build process.

%BuildRunner% Always "MyGet", can be used to determine if running on MyGet Build Services
%NuGet% Path to a maintained-by-MyGet NuGet.exe
%SourcesPath% Path to source code being built
%Configuration% Build configuration (defaults to Debug)
%Platform% Platform to build (defaults to blank)
%VersionFormat% Version format specified in build configuration
%BuildCounter% Build counter value
%PackageVersion% %VersionFormat% with %BuildCounter% filled in, used as the auto-generated package version number
%EnableNuGetPackageRestore% NuGet package restore enabled? Always true.

 

Package Source Configuration

We've also pulled Package Sources out of beta for everyone to enjoy, including our Free users! Package sources play a key role in the MyGet Build Services workflow. By default, the NuGet Gallery is configured as an upstream package source. You could obviously also configure Chocolatey, an Orchard feed, or your own MyGet feed, or all of them! These upstream package sources allow you to reference or mirror packages onto your own feed. It also allows you to easily push packages from your feed to the the upstream package source, given you configured your API key in the package source configuration.

When you want to push a package upstream, you'll be prompted with a dialog asking you which upstream feed should be used. In addition, you'll also get the opportunity to modify the package version as it should appear on the upstream package source. Note that no compilation is happening, we're simply adjusting the package version if you changed it. Because semantically nothing changed to the package, you'll only be able to change the -PreRelease tag, or simply remove it and make your upstream package a full release.

Without enforcing them

We won't enforce you in using SemVer as this would introduce friction for those who don't want to use it. It's not up to the repository host to define your versioning approach: this is the responsibility of the feed owner. This is impossible on NuGet.org as the feed is owned by the Community, which is definitely not organized around a single common versioning scheme.

However, if you - as a MyGet feed owner - want to enforce it, then you can by simply checking the appropriate checkbox in your feed settings. We try to find a balance between removing friction and providing freedom in your choices, so we hope you like it! Don't hesitate to send us your feedback or log them on our UserVoice.

Happy Packaging!

New features in MyGet Enterprise

The MyGet Enterprise plan was introduced a couple of months ago and has had several management options since then. After logging in to your MyGet Enterprise instance the main menu displays a Dashboard link which gives the plan administrator access to a management dashboard.

MyGet Enterprise administration

In the management dashboard, MyGet Enterprise administrators can view statistics on their instance (number of feeds, storage usage, some aggregates on consumption and so on) as well as manage several options for their instance such as managing users, feeds, Google Analytics integration, SymbolSource integration, SMTP settings and quota management. With the 1.6 release of MyGet, we’ve added several other options to this enterprise management dashboard. And of course, your MyGet Enterprise plan also contains all of the enhancements that were introduced on the public MyGet website as well (such as retention policies, feed activity logs, build services, download as ZIP and much more).

Block e-mail addresses not belonging to the organization

Enterprise users not using Active Directory integration but instead relying on social identity providers like Microsoft Account or Google Account previously had no option for blocking users not belonging to their organization from creating an account on their MyGet Enterprise instance. Starting today, domain names for e-mail addresses can be whitelisted or blacklisted.

image

If your enterprise has Google Account e-mail addresses which all end in “@acmecorp.com", adding a whitelist entry for “acmecorp.com” will allow only those users to create an account on your MyGet Enterprise plan. Multiple entries can be entered, separated by a semicolon.

Users can be made administrator

Before our 1.6 release, multiple administrators per MyGet Enterprise instance were already a possibility but could only be managed by sending our support people an e-mail. Because this is a common task, we now made it possible for existing MyGet Enterprise administrators to grant or revoke administration privileges to users in their organization.

image

User removal

What happens if a user for a MyGet Enterprise instance leaves the organization? With our new release, users can be deleted from a MyGet Enterprise instance by clicking the Delete button on the user management pages.

image

By default, the user and its feeds will be removed. This is not always something you will want to do: what if that user is the owner of a production MyGet feed? The delete user dialog allows you to transfer feed ownership for all of the user’s feed to another user in your organization.

More information about our MyGet Enterprise plan can be found on the MyGet Enterprise plan page.

Happy packaging!

Introducing activity streams

In a previous post we highlighted the new user profile page and briefly mentioned we are working on activity streams. If you look at the Activity tab of your profile, you'll still see that it is coming soon.

We are still working on the UI for this part, but before we introduce it to the masses we need to take care of a few more things. No worries, a clear communication about these changes will be done upfront, and we obviously will keep private feed activity secured. A lot of stuff is happening under the hood, really, in order for this feature to be rolled out smoothly. Our incremental and short release cycles are starting to pay off (or you'd end up with blank activity streams upon release).

However, you might notice that we already built an initial UI for the feed activity. Simply take a look at your feed details page and check the Feed Activity tab on the left menu.

We are working hard on providing you with historic information on packages and feeds throughout the site so expect more to come soon. We believe this will greatly improve the experience of both package publishers as consumers, as well as those interested to keep up with what's happening on the feed or with a specific package. There's some great stuff on some of the feeds in our Gallery and we'd like to give you the opportunity to get notified of the package repository events you want to track.

The below screenshot also gives you an idea of the kind of activity you might be interested in: adding or deleting packages, unlisting packages, pushing packages to an upstream package source (e.g. to NuGet.org), etc. The particular feed activity you can see below is the result of how we push the GoogleAnalyticsTracker package to NuGet.org.

Happy New Year & Happy Packaging!

NuGet package restore from a secured feed

One of the most frequently asked questions at MyGet is the following one (we have pending updates to our FAQ section):

How do I set up NuGet package restore against a private MyGet feed requiring authentication?

This is also one of the things you might end up doing when debugging NuGet package restore issues.

For public feeds, you only need to change the repository URL in the nuget.targets file to let your build server know from where it needs to fetch the packages. For private feeds however, there are a few things you need to know.

Which credentials should I use?

At MyGet, we recommend you to create a separate account for your build agents and give it specific permission on your feed (e.g. readonly or read/write, but no additional permissions).

It is not a technical requirement though: you could simply use your personal account, but please be aware that in this case you share your credentials!

As you'll see in this post, you can store the credentials for the build service account on the build agent(s) without having to share them with anyone. Using a user's account for the build agent can break anyone's build if access for this user is revoked...

Visual Studio will prompt for credentials

As soon as you try to communicate with a secured package source in Visual Studio, it will prompt you for credentials. So why do you get the following build error when using package restore?

There's no non-interactive way to provide credential parameters

NuGet package restore relies on the NuGet.exe commandline tool by using the install command. The commandline will either prompt you for credentials (which isn't suitable for automated build scenarios), or will look for credentials in nuget.config file in %AppData%\NuGet\nuget.config (if you use the Non-Interactive option).

The latter looks like what you need in automated build scenarios, but requires you to store feed credentials on the machine, for the user account that will perform the build. This can become cumbersome if you have a multitude of solutions using this feature.

Hierarchical NuGet.config doesn't take credentials into account (yet!)

The latest version of NuGet has support for hierarchical nuget.config files, which is an attempt to overcome the need to store everything on the machine. It allows you to have a solution-level NuGet configuration which should be taken into account during package restore.

This means that feed URL and credentials could be stored next to your solution instead of being pre-configured in the user profile. However, credentials aren't picked up (yet), and there's no easy way to store them (encrypted) into any nuget.config file other than the one in your roaming user profile (explained in the next section of this post).

This is a known issue which seems to be fixed in vNext of NuGet. Check this Codeplex issue for more details. Not sure though whether this will be facilitated without having to copy-paste those encrypted credentials from one config to another.

You can store feed credentials in your user-profile NuGet.config

That's likely to be the easiest approach: as you register the package source URL, you might want to save the required credentials as well. This is however not exposed in the Visual Studio NuGet Package Manager extension, so you'll have to use the NuGet.exe commandline tool. The following gist illustrates a few of these options that should help you configure your secured feed, including credentials.

MyGet logo stickers

We're fairly sure the mailman didn't know he was carrying more than one package this morning when handing over the enveloppe. To celebrate our new logo, we've been handing out free subscriptions to our Starter plan during the past few days. Follow us on Twitter for future announcements (our Features page is growing!) and perhaps a chance to win.

Today we're happy to announce we'll be handing out some of these cool stickers during our upcoming trips! Thank you StickerMule for a job well done!

Want to get some? Then don't miss the opportunity to meet our team members and learn how we built MyGet at these upcoming events:

See you there & Happy Packaging!

Update project templates to the latest NuGet packages

We noticed a question on StackOverflow that proved we weren't the only ones finding it a little sub-optimal having to update NuGet packages right after creating a new project.

Most of us are likely to use the default project templates that come with Visual Studio or an SDK. Let's take the example of the MVC4 project template for C#, using Razor syntax.

MVC4 C# Web application template using Razor syntax

 

This project template is consuming quite a few NuGet packages by default. jQuery is one of them. The whole point is that these NuGet packages can be updated more frequently and independent from any pending SDK update or other product release. This is a good thing!

As a direct consequence, this also means that the default templates become "outdated". Outdated is a strong word, as the template itself isn't really outdated, but rather the packages list it wants to consume from NuGet. jQuery is one of those packages that gets very frequent updates. There's an easy way to update all packages in a solution all at once. Use the Package Manager Console, type

Update-Package

and hit ENTER. Done!

But why not avoid this step (or at least partially) and change the defaults?

Note: We'd recommend you to create your own project template so you can always revert back to the default one in case you, or someone else, is going to mess things up :)

All Visual Studio (2012) project templates can be found here:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\

If you want to create some custom project templates, I'd recommend you to create them here:

%USERPROFILE%\Documents\Visual Studio 2012\Templates\ProjectTemplates

In this post, we'll show you how you can change the defaults for the MVC4 CSHTML project template. You can find it here:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033\MvcWebApplicationProjectTemplatev4.0.cshtml\

To modify the files, you'll have to edit them as Administrator (you know the drill, right-click Notepad++ or Sumblime and click Run As Administrator).

The file you'll want to take a look at is the .vstemplate file. It's an XML file containing template instructions for Visual Studio. Look for a section called packages. It should look something like this:

<WizardData> 
<packages repository="registry" keyName="AspNetMvc4VS11" isPreunzipped="true"> 
<package id="EntityFramework" version="5.0.0" skipAssemblyReferences="true" /> 
<package id="jQuery" version="1.7.1.1" />
...

Let's take jQuery as an example again: we want to upgrade the dependency to version 1.8.2 by default.

To do so, you modify the above snippet to look like this:

<WizardData>
<packages repository="registry" keyName="AspNetMvc4VS11" isPreunzipped="true">
<package id="EntityFramework" version="5.0.0" skipAssemblyReferences="true" />
<package id="jQuery" version="1.8.2" />
...

Easy huh?

Now you found the candy, you can change the default installed package versions, or even add or remove the packages you want. Whatever you do, make sure you don't break the template so proceed with caution. If you remove a package dependency, make sure you remove any dependent configuration or references in the project template's files. If you update a package to a newer version, make sure those dependent configurations are updated as well.

Take a look at the project template's Scripts folder. You see that little _references.js file?

This is a harmless example of things that can be left behind and out-of-sync with the package edits you make. Open the file (run as administrator) and update those references accordingly. The jQuery reference should now be the following:

/// <reference path="jquery-1.8.2.js" />

Ever wondered why you didn't have to be online to be able to create a new MVC project and consume all those packages? Then check this folder and be amazed:

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Packages

Obviously, the packages you want to support in your default project templates should be available there as well, so download those NuGet packages and extract them here. You can download the NuGet package after logging in to NuGet.org: look for the package you want, select the version you need, and you'll notice a download link on the left side.

Download a NuGet packages from the Gallery

Once downloaded, unblock the package (right-click, properties, unblock), copy it to the packages directory (C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Packages). Next, unzip it, and remove all garbage. The relevant content is selected on the following screenshot. Ensure you rename the .nuspec file by adding the version in front of it, e.g. jquery.1.8.2.nuspec.

Relevant package contents

From now on, all newly created default MVC4 CSHTML Web projects will already contain the updated jQuery dependency.

Feature highlight: MyGet Gallery

It's been less than two months since we introduced the public MyGet Gallery, and we are very happy to have some awesome projects onboard, often shipping development builds or using MyGet as a staging environment before pushing packages upstream. These feeds deserve more attention and people should know these feeds exist.

Did you know you can get the latest development builds of SignalR and MVC Contrib delivered through MyGet?

If you think your project's development builds deserve a place in our Gallery, you can easily opt-in using your feed's Gallery Settings.

Gallery feed readme

Our latest v1.3 release now allows feed owners to add a feed readme for publication in the MyGet Gallery. This way, feed owners now can easily add some instructions or disclaimers to the gallery feed details page using the well-known markdown format. Don't forget to add a link to your project page and/or sources as well.

You might recognize the pagedown markdown editor there, which is also used on the StackExchange Web sites, so you are probably already familiar with it. In return for this excellent control, we also added the StackOverflow identity provider to our login page. People who prefer to login using their StackOverflow account can now do so, or you can link it to your other identities within your MyGet account as well.

Layout improvements

While at it and based on the invaluable feedback of our users, we also improved the look-n-feel of the packages and feed listings by removing clutter and putting focus on content.

You can now not only see which packages are listed, and what version they're at, but you can also track when this version has become available. A simple click on the icon next to the package will trigger a package download in your browser, whilst the icons on the top right bring you to the SymbolSource symbols repository of this feed (if available) or give access to the RSS feed associated with this package repository.

What's next?

The screenshot below (taken from our latest development builds) is giving you a glimpse at what's coming next: user profiles and activity streams! That's right: you'll be able to get insights into the activity of a public feed or track the history of a given package. Coming soon...

We hope you like it! Keep those suggestions and feedback coming! Who knows, maybe one day you'll see your wish granted :)

Happy packaging!