Using VSO Build vNext and MyGet

As people are using Visual Studio Online in combination with MyGet, we often get the request to help them set things up. We do have documentation VSO integration, but the new VSO Build Preview deserves a dedicated blog post. This blog post should guide you through the setup experience and get you going in no time!<div>
</div><h1>Configuring Package Restore</h1><div>One of the first and most easy things to do is to configure NuGet package restore in your solution.</div><div>
</div><div>When creating a MyGet feed, by default, we will configure as an upstream package source. What is very convenient is that you can tweak it further so that:</div><div><ul><li>clients querying your MyGet feed also query the upstream package source to resolve packages</li><li>the downstream MyGet feed automatically mirrors the packages queried upstream (thus creating a copy of the package on your MyGet feed)</li><li>you don’t see the mirrored packages in your MyGet feed, even though they’re there and can be restored (the concept of ‘unlisting’ a package)</li></ul><div>Three simple checkboxes in the package source configuration make the above possible, as shown below:</div></div><div>
</div><div>Once enabled, you should see the below package source configuration updated to reflect those changes.</div><div>
</div><div>In the code base, you should ensure you have a nuget.config file in the solution root directory. This is where you can configure NuGet package restore configuration options, including credentials for your private feed. The below snippet is a good sample of what you need there.</div><div></div><div>
</div><div>Be sure to add the nuget.config file to your version control system to ensure the build server also has it available.</div><div>Also, be sure to check this NuGet docs article on how to ommit packages from source control. Git users can simply ignore the packages folder in the .gitignore file, TFVC users need to create an additional nuget.config file in a directory called .nuget (created in the solution root directory). This may change in the future, so be sure to check the docs!</div><div>
</div><div>That’s it! You can now locally restore packages in your solution from both MyGet and</div><div>All you need to do in VSO Build Preview is to create a new Build Definition using the default Visual Studio build template and queue a build. </div><div>
</div><div>If you consume NuGet packages, you should now already see package restore actions in the build log.</div><div>
</div><h1>Creating NuGet packages</h1><div>For demo purposes, I’m building a simple class library and want to package-n-publish it to MyGet. We highly recommend you first create a .nuspec file for the project you want to package. You can construct this NuGet package manifest yourself, use NuGet Package Explorer, or if you have nuget.exe at your disposal, simply run nuget spec in the folder where your target project is located. </div><div>
</div><div>Note: if you run nuget spec, please ensure you have all required metadata in your AssemblyInfo file to provided the tokenized nuspec file with actual values during packaging.</div><div>
</div><div>To create the NuGet packages, you’ll need to add a PowerShell script build task to the build definition and call into nuget pack.</div><div>
</div><div>// todo: sample</div><div>// add NuGet packaging logic to the custom build task?</div><div>
</div><h1>Publish NuGet packages to MyGet</h1><div>// todo: preferably based on the custom build task</div><div>// otherwise: PoSh it..</div><div>

Author: Xavier Decoster on 27 May 2015

Introducing MyGet Vsix support–Visual Studio Extensions and Roslyn

Last month, we introduced a limited preview for Visual Studio extensions (Vsix) on MyGet. Today, we’re proud to announce Vsix support has been enabled for all MyGet customers! In this blog post, we’ll see how we can use MyGet to build and distribute a Roslyn analyzer and code fix, as a NuGet package and a Visual Studio extension.

The full feature set we already have for NuGet, Bower and NPM is now also available for Vsix. You're able to manage extensions, add them from upstream feeds (ATOM only), granular permissions and user management, support for community feeds... If you need a staging feed or just a private VSIX gallery, this is the easiest way to get one. Using the VSO integration? We'll pick up the VSIX artifacts from your VSO build and automatically add them to your MyGet VSIX feed. Here’s an example.

(we also open sourced the example at

Developing a Roslyn analyzer and code fix

Roslyn analyzers and code fixes allow development teams and individuals to enforce certain rules within a code base. Using code fixes, it’s also possible to provide automated “fixes” for issues found in code. When writing code that utilizes DateTime, it’s often best to use DateTime.UtcNow instead of DateTime.Now. The first uses UTC timezone, while the latter uses the local time zone of the computer the code runs on, often introducing nasty time-related bugs. Let’s write an analyzer that detects usage of DateTime.Now!

You will need Visual Studio 2015 RC and the Visual Studio 2015 RC SDK installed. You’ll also need the SDK Templates VSIX package to get the Visual Studio project templates. Once you have those, we can create a new Analyzer with Code Fix.

New Roslyn analyzer

A solution with 3 projects will be created: the analyzer and code fix, unit tests and a Vsix project. Let’s start with the first: detecting DateTime.Now in code an showing a diagnostic for it. It’s actually quite easy to do: we tell Roslyn we want to analyze IdentifierName nodes and it will pass them to our code. We can then see if the identifier is “Now” and the parent node is “DateTime”. If that’s the case, return a diagnostic:

public override void Initialize(AnalysisContext context) { context.RegisterSyntaxNodeAction(AnalyzeIdentifierName, SyntaxKind.IdentifierName); } private void AnalyzeIdentifierName(SyntaxNodeAnalysisContext context) { var identifierName = context.Node as IdentifierNameSyntax; if (identifierName != null) { // Find usages of "DateTime.Now" if (identifierName.Identifier.ValueText == "Now" && ((IdentifierNameSyntax)((MemberAccessExpressionSyntax)identifierName.Parent).Expression).Identifier.ValueText == "DateTime") { // Produce a diagnostic. var diagnostic = Diagnostic.Create(Rule, identifierName.Identifier.GetLocation(), identifierName); context.ReportDiagnostic(diagnostic); } } }

If we compile our solution and add the generated NuGet package to another project, DateTime.Now code will be flagged. But let’s implement the code fix first as well. We want to provide a code fix for the syntax node we just detected. And when we invoke it, we want to replace the “Now” node with “UtcNow”. A bit of Roslyn syntax tree fiddling:

public sealed override async Task RegisterCodeFixesAsync(CodeFixContext context) { var root = await context.Document.GetSyntaxRootAsync(context.CancellationToken).ConfigureAwait(false); var diagnostic = context.Diagnostics.First(); var diagnosticSpan = diagnostic.Location.SourceSpan; // Find "Now" var identifierNode = root.FindNode(diagnosticSpan); // Register a code action that will invoke the fix. context.RegisterCodeFix( CodeAction.Create("Replace with DateTime.UtcNow", c => ReplaceWithDateTimeUtcNow(context.Document, identifierNode, c)), diagnostic); } private async Task<Document> ReplaceWithDateTimeUtcNow(Document document, SyntaxNode identifierNode, CancellationToken cancellationToken) { var root = await document.GetSyntaxRootAsync(cancellationToken); var newRoot = root.ReplaceNode(identifierNode, SyntaxFactory.IdentifierName("UtcNow")); return document.WithSyntaxRoot(newRoot); }

That’s it. We now have an analyzer and a code fix. If we try it (again, by adding the generated NuGet package to another project), we can see both in action:

MyGet Roslyn analyzer VSIX and NuGet

Now let’s distribute it to our team!

Distributing a Roslyn analyzer and code fix using MyGet

Roslyn analyzers can be distributed in two formats: as NuGet packages, so they can be enabled for individual project, and as a Visual Studio extension so that all projects we work with have the analyzer and code fix enabled. You can build on a developer machine, a CI server or using MyGet Build Services. Let’s pick the latter as it’s the easiest way to achieve our goal: compile and distribute.

Create a new feed on Next, from the Build Services tab, we can add a GitHub repository as the source. We’ve open-sourced our example at so feel free to add it to your feed as a test. Once added, you can start a build. Just like that. MyGet will figure out it’s a Roslyn analyzer and build both the NuGet package as well as the Visual Studio extension.

MyGet automated build of visual studio extension

Sweet! You can now add the Roslyn analyzer and code fix per-project, by installing the NuGet package from the feed ( ANd when registering it in Visual Studio ( by opening the Tools | Options... menu and the Environment | Extensions and Updates pane, you can also install the full extension.

Private VSIX feed with MyGet

Give it a try! More info is available from the Visual Studio extension landing page or the documentation on using MyGet’s Vsix features.

Happy packaging!

Author: Maarten Balliauw on 08 May 2015

Working with scoped npm packages and MyGet private registry

When we introduced npm support on MyGet last month, we did not yet have support for scoped packages. Today, we’re pleased to announce full support for them!

Scoped packages are packages that are "scoped" to a specific registry. E.g. all packages scoped @acmecorp may be retrieved from a MyGet npm registry feed, while other scopes and non-scoped packages flow in from the default npm registry.

Creating a scoped package

A scoped package can be created by setting the name property in package.json file correctly, for example:

  "name": "@acmecorp/awesomeapplication",
  "version": "1.0.0"

Dependencies can be scoped as well:

  "name": "@acmecorp/awesomeapplication",
  "version": "1.0.0",
  "dependencies": {
    "@acmecorp/awesomepackage": "1.0.0"

More information on scoped packages is available from the npm docs.

Publishing a scoped package

Scopes can be associated with a specific registry. This allows for seamless mixing of packages from various npm registries.

Let's associate the scope @acmecorp with the npm registry feed. We can do this manually, by adding the following to our .npmrc file:


It's probably easier to generate these entries from the command line by running:

npm config set @acmecorp:registry=
npm login --registry --scope=@acmecorp
npm config set always-auth true --registry

From now on, we can publish and consume any package that has the @acmecorp scope. Npm will automatically direct requests to the correct registry.

Happy packaging!

P.S.: We have VSIX support coming as well. Let us know if you want to enroll in the preview.

Author: Maarten Balliauw on 14 Apr 2015

Limited preview - VSIX support

MyGet has a rich feature set for NuGet, and we just recently added support for Bower and NPM registries. Now we'd like to give our users the opportunity to bring those rich MyGet features to VSIX as well!

What VSIX support will you get in this preview?

We currently have the full feature set we already have for NuGet, Bower and NPM. You'll be able to manage extensions, add them from upstream feeds (ATOM only), granular permissions and user management, support for community feeds... If you need a staging feed or just a private VSIX gallery, this is the easiest way to get one. Using the VSO integration? We'll pick up the VSIX artifacts from your VSO build and automatically add them to your MyGet VSIX feed.

I want to join the preview!

If you are interested in joining the private preview and eager to provide some early feedback, then just ping us with your username and we'll flip the feature toggle for your account.

Author: Xavier Decoster on 07 Apr 2015

MyGet now offers NuGet, Npm and Bower registries

pmsWith our latest MyGet release, we’ve added support for npm and bower registries. We’ve always been very focused on building a great story around NuGet and decided it was time for Npm and Bower enthusiasts to get a similar experience.

Adding npm and Bower support was high on our wish list and that of our users. Many developers are doing only front-end development and need a public or private npm registry. Others are working with DNX (the new name for ASP.NET 5 or ASP.NET vNext) and combine NuGet, npm and Bower. It feels good to be able to support them all!

To help you get started, we’ve prepared a few short tutorials that help you get started on MyGet with these package managers:

Oh and build services now also packages node modules! Just point MyGet to your GitHub repository and we’ll package your npm packages, too.

We really look forward to hearing your feedback on this!

Happy packaging!

Author: Maarten Balliauw on 16 Mar 2015

MyGet 2.0 Release Notes

MyGet 2.0 was released on March 12, 2015.


This 2.0 release of MyGet adds brand new functionality to the service. With this release, we bring all the functionality we already had for NuGet also to Bower and NPM!

This means, from now on, you can use MyGet to host and build your own NuGet, NPM or Bower feeds, whether public or secured.

<h3 id="Features">Features</h3><h4 id="MyGet_all_plans">MyGet (all plans)</h4><p>The following applies to all MyGet plans:</p><ul><li>NPM support!</li><li>Bower support!</li><li>Integrated FastSpring as payment provider with support for subscription auto-renewal</li><li>NuGet: (IE-only) new link on package details page to open NuGet packages directly in NuGet Package Explorer</li><li>NuGet: support for v2 Target Framework filtering</li><li>NuGet: modify NuGet package description and release notes before pushing upstream</li></ul><h4 id="MyGet_paid_plans">MyGet (paid plans)</h4><p>Obviously all paid plans also get the enhancements made available on the free plan. The following applies to the MyGet Starter and Professional plans:</p><ul><li>NuGet: New MyGet Feed Sync service</li></ul><h4 id="MyGet_Enterprise">MyGet Enterprise</h4><p>The enterprise plan has all functionality from the paid subscription plans, and more! The following applies only to the MyGet Enterprise plan:</p><ul><li>Allow customization of the message displayed on the login page</li><li>Support domain whitelisting/blacklisting using wildcards for registration email address</li><li>Support IP address range whitelisting/blacklisting</li></ul><h4 id="MyGet_Build_Services">MyGet Build Services</h4><ul><li>Support for pre- and post-build step scripts</li><li>Support for service messages</li><li>Support for user-defined environment variables</li><li>Support for user-defined environment variable expansions</li></ul><h3 id="Bug_Fixes">Bug Fixes</h3><ul><li>Improved detection of hanging builds</li><li>Build now properly fails when compilation fails and no packages have been produced or pushed to your feed</li><li>Upstream package source proxying enhancements</li><li>No longer prompt the user that a package update is available upstream if the package source is set to auto-update</li></ul><p>Keep that feedback coming! MyGet is built for you!</p><p>Happy packaging!</p><p>

Author: Xavier Decoster on 13 Mar 2015

Introducing MyGet Feed Sync

How can you keep multiple local NuGet servers synchronized? How can developers consume the same packages when each office branch has its own local NuGet server? How can two servers be synchronized when bandwidth is insufficient for a cloud-only solution?

We’re happy to introduce Feed Sync. Jointly developed by MyGet and Inedo ProGet, allows you to synchronize packages on multiple package servers with MyGet.

Note: During preview, Feed Sync is available for all MyGet plans and Inedo ProGet free users. After release, Feed Sync will be available for all paid MyGet plans and users of ProGet Enterprise 3.5 and up.

Synchronize local NuGet server with MyGet

Packages added on a linked ProGet instance will be replicated to MyGet and any other linked instance. When using MyGet Build Services to build packages from GitHub, BitBucket or Visual Studio Online, packages that are created will be replicated as well.

Read up on how to configure Feed Sync in our documentation.

Happy packaging!

Author: Maarten Balliauw on 28 Jan 2015

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!

Author: Xavier Decoster on 13 Jan 2015