MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Dropbox as a package source for NuGet, npm, Bower and VSIX packages

Wouldn’t it be awesome if creating a NuGet, npm, Bower or VSIX feed was as easy as just copying packages into a Dropbox folder? Awesomeness is here: we’ve added Dropbox as a package source type to MyGet. This allows us to link a Dropbox folder to a MyGet feed and automatically upload packages so they can be consumed with the popular package managers out there.

Synchronizing NuGet packages with Dropbox

The Dropbox package source makes it easy to move packages into MyGet. For example, migrating from a network share to MyGet is as easy as copy-paste. Have a build server that drops artifacts into a Dropbox folder? MyGet will add the synchronized artifacts to your feed. Right now we download packages from Dropbox on a schedule (every 15 minutes).

Give it a try and let us know how it goes – feedback is welcome through the comments below or via the MyGetTeam Twitter account.

Happy packaging!

Adding another MyGet feed as a package source - Feed presets

Many people are using multiple MyGet feeds in their development flow, and have good reasons to do so. Some are pushing packages from one feed to another as they promote them through quality gates. Others are proxying upstream feeds or filtering packages downstream.

MyGet supports many types of package sources, and as flexibility is great, configuration can be a little tedious or even error prone.
Why would we ask our users to provide us with their MyGet feed url if we know what feeds the user collaborates on? We realized we could do better. In addition to the already rich list of presets, we have added a convenient button that lists your MyGet feeds.



It works the same way as the presets, and will populate your package source name and URL. This convenience helps avoid wasting time configuring your package management workflow and ensures the upstream feed is configured correctly.

Happy packaging!

PS: At MyGet, reducing friction is a feature. One that we consider most important! After all, that's how we have been able to deliver a smooth package management experience, serving over 16 billion package downloads over the past few years. Have a feature request or an enhancement you'd like to see? Please reach out to us!

Improved support for localized satellite NuGet packages

At MyGet, we live and breath a culture of componentization, and we are very happy to see package authors adopting and sharing these practices within their organizations. One of these practices is the usage of NuGet's localized NuGet packages feature. The adoption of localized satellite packages is a good indicator of package author maturity. Using a better practice should be rewarding and free of friction. One of our Dear Users provided us with great feedback on how he leveraged MyGet to release localized packages by pushing them upstream. However, some unnecessary friction was involved, which had to be removed.

Localized NuGet Packages

As a NuGet package author, you can provide a localized experience for your libraries. The NuGet client has supported the creation of localized satellite packages since version 1.8.

For those unfamiliar with the concept, here's a basic package graph demonstrating the idea:

My.Framework.1.0.0-alpha0001.nupkg

  • Meta package, installing My.Framework and all localized satellite packages
  • Depends on: all satellite packages (My.Framework.Core.nl, My.Framework.Core.fr, My.Framework.Core.el, ...)
My.Framework.Core.1.0.0-alpha0001.nupkg
  • Package containing an actual framework library (e.g. in lib/net45/My.Framework.Core.dll)
  • No dependencies for the sake of the demo (your libraries most likely have dependencies :))
My.Framework.Core.nl.1.0.0-alpha0001.nupkg
My.Framework.Core.fr.1.0.0-alpha0001.nupkg
My.Framework.Core.el.1.0.0-alpha0001.nupkg
  • 3 localized satellite packages for the My.Framework.Core package
  • Depends on the actual framework package being localized: My.Framework.Core.1.0.0-alpha0001.nupkg
  • Only contains localization resources (e.g. lib/net45/nl/My.Framework.Core.resources.dll, lib/net45/nl/My.Framework.Core.xml)
Or visualized in a graph, here's the dependency tree:


To facilitate discovery of these satellite packages, we added a convenient Localization tab on the package details page if localized satellite packages are detected.


Releasing localized NuGet packages

Ideally, releasing a package that has localized satellite packages from MyGet to another feed, should be a click of a button away, publishing the entire package-set at once. Optionally, one might also want to adjust the prerelease tag and release notes of this package set, either per package individually, or for all at once.

The Push Upstream feature (also check our docs) has been upgraded to now also detect package dependencies and localized satellite packages!

This means that, as in the above sample scenario, you can now publish the entire localized package-set in one go by pushing the My.Framework meta package upstream.


In addition, you can also edit (or simply remove!) the prerelease tag and/or release notes for each package individually, or for all of them at once!

Simply click the edit button  next to one of the packages, modify the fields, and click the water-drop icon  to apply the changes to all other packages in the dialog.


Of course, you can still exclude individual packages from this list if you want to by clicking the  button next to the respective package.

We love this kind of feedback and hope you find this change useful, so keep the feedback coming!

Happy Packaging!

Introducing debugging, source code and symbols for NuGet packages

Shortly after we launched MyGet, we teamed up with SymbolSource.org to provide support for .NET debugger symbols. Today, we’re happy to announce a second option: integrated MyGet symbols support! MyGet symbols support lets consumers of our NuGet packages step through the source code and integrate with Visual Studio and tools like WinDbg. Additionally, symbols and sources can be consumed from within MyGet as well.

Head over to our docs and learn how to get started with MyGet symbols support!

image

How do I get started?

Documentation is available that will help you get started with MyGet symbols very quickly. Symbols in .NET can be tricky sometimes, so if things don’t work out as expected we’ve also compiled a list of PDB troubleshooting tips.

To make things easy, the endpoint for pushing symbols packages is the same as that for your regular NuGet packages: https://www.myget.org/F/<feedname>/api/v2/package. MyGet will determine the type of package and act accordingly. This makes pushing symbols packages from your build server, like TeamCity or Visual Studio Team Services similar to pushing regular NuGet packages.

Where do my symbols packages go when I use MyGet Build Services?

For new feeds, symbols packages are pushed to your MyGet feed by default. For existing feeds, symbols will be uploaded to SymbolSource (if this was enabled). From the build configuration, you can select where to push symbols packages.

What happens to the SymbolSource integration?

SymbolSource integration is still available. Our customers asked very loudly for integrated symbols support, so we’re delivering on that. We are still providing the option to use SymbolSource with your MyGet feeds. In fact, they have some great new features planned as well!

Head over to our docs and learn how to get started with MyGet symbols support!

Happy packaging! (and efficient debugging, of course)

Package details showing GitHub project README

We’re happy to introduce a few user interface enhancements which have been available for all users of npm private feeds on MyGet. We’ve now rolled these out to the package details page for NuGet, npm, Bower and Vsix packages. These pages now display all “at-a-glance” information on the right. Package owners, authors, license information and downloads can be seen from here.

The wider part of the package details page now displays the README.md contents retrieved from GitHub. That is, if the GitHub repository is accessible for us. This makes it easier for consumers of your feed to see installation instructions, links to documentation and so on from the package details page.

MyGet showing GitHub readme contents on package details page

We're looking forward to hearing your feedback through the comments below. Or tweet us via @MyGetTeam.

Happy packaging!

Working with a private npm registry in Azure Web Apps

Using Azure Web Apps, we can deploy and host Node applications quite easily. But what to do with packages the site depends on? Do we have to upload them manually to Azure Web Apps? Include them in our Git repository? None of that: we just have to make sure our app’s package,json is checked in so that Azure Web Apps can install them during deployment. Let’s see how.

Installing node modules during deployment

In this blog post, we’ll create a simple application using Express. In its simplest form, an Express application will map incoming request paths to a function that generates the response. This makes Express quite interesting to work with: we can return a simple string or delegate work to a full-fledged MVC component if we want to. Here’s the simplest application I could think of, returning “Hello world!” whenever the root URL is requested. We can save it as server.js so we can deploy it later on.

var express = require("express"); var app = express(); app.get("/", function(req, res) { res.send("Hello world!"); }); console.log("Web application starting..."); app.listen(process.env.PORT); console.log("Web application started on port " + process.env.PORT);

Of course, this will not work as-is. We need to ensure Express (and its dependencies) are installed as well. We can do this using npm, running the following commands:

# create package.json describing our project npm init # install and save express as a dependency npm install express --save

That’s pretty much it, running this is as simple as setting the PORT environment variable and running it using node.

set PORT=1234 node server.js

We can now commit our code, excluding the node_modules folder to our Azure Web App git repository. Ideally we create a .gitignore file that excludes this folder for once and for all. Once committed, Azure Web Apps starts a convention-based deployment process. One of the conventions is that for a Node application, all dependencies from package.json are installed. We can see this convention in action from the Azure portal.

Azure Deploy Node.JS

Great! Seems we have to do nothing special to get this to work. Except… What if we are using our own, private npm modules? How can we tell Azure Web Apps to make use of a different npm registry? Let’s see…

Installing private node modules during deployment

When building applications, we may be splitting parts of the application into separate node modules to make the application more componentized, make it easier to develop individual components and so on. We can use a private npm registry to host these components, an example being MyGet. Using a private npm feed we can give our development team access to these components using “good old npm” while not throwing these components out on the public npmjs.org.

Imagine we have a module called demo-site-pages which contains some of the views our web application will be hosting. We can add a dependency to this module in our package.json:

{ "name": "demo-site", "version": "1.0.0", "description": "Demo site", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "dependencies": { "express": "^4.13.3", "demo-site-pages": "*" } }

Alternatively we could install this package using npm, specifying the registry directly:

npm install --save --registry https://www.myget.org/F/demo-site/npm/

But now comes the issue: if we push this out to Azure Web Apps, our private registry is not known!

Generating a .npmrc file to work with a private npm registry in Azure Web Apps

To be able to install node modules from a private npm registry during deployment on Azure Web Apps, we have to ship a .npmrc file with our code. Let’s see how we can do this.

Since our application uses both npmjs.org as well as our private registry, we want to make sure MyGet proxies packages used from npmjs.org during installation. We can enable this from our feed’s Package Sources tab and edit the default Npmjs.org package source source. Ensure the Make all upstream packages available in clients option is checked.

(more details on this feature in the documentation on using MyGet with npm)

Next, register your MyGet NPM feed (or another registry URL). The easiest way to do this is by running the following commands:

npm config set registry https://www.myget.org/F/your-feed-name/npm npm login --registry=https://www.myget.org/F/your-feed-name/npm npm config set always-auth true

This generates a .npmrc file under our user profile folder. On Windows that would be something like C:\Users\Username\.npmrc. Copy this file into the application’s root folder and open it in an editor. Depending on the version of npm being used, we may have to set the always-auth setting to true:

registry=https://www.myget.org/F/demo-site/npm //www.myget.org/F/demo-site/:_password="BASE64ENCODEDPASSWORD" //www.myget.org/F/demo-site/:username=maartenba //www.myget.org/F/demo-site/:email=maarten@myget.org //www.myget.org/F/demo-site/:always-auth=true

If we now commit this file to our git repository, the next deployment on Azure Web Apps will install both packages from npmjs.org, in this case express, as well as packages from our private npm registry.

Installing node module from private npm registry

Happy packaging!

Preview support for the NuGet V3 protocol

A few weeks back, NuGet 3.0 was released. It’s a redesign of the NuGet client targeted at Visual Studio 2015, with a number of improvements and changes from earlier versions of NuGet. One of the changes the NuGet team made was on the server side, with a new protocol. We’re happy to announce that MyGet now has preview support for this new protocol as well!

The new NuGet server-side API was first written about in April 2014. And even before that, there was a talk Evolution of NuGet at MonkeySpace 2013. In it, the NuGet team describes what the NuGet team envisioned: a faster and more reliable API for .NET developers to consume packages. When opening the NuGet Package Manager Dialog in Visual Studio 2015 this becomes very visible: the well-known OData V2 feeds feel slow. MyGet now supports the NuGet V3 protocol (in preview), sharing the vision the NuGet team laid out over 2 years ago and made happen a few weeks ago: make NuGet package management faster.

Note: make sure to read the entire blog post when using private feeds - the NuGet client that ships with Visual Studio 2015 NuGet only supports pre-authenticated V3 feeds. An update is available with full private feed support.

How to make use of the NuGet V3 protocol with MyGet?

The URL of a MyGet feed typically looks like this: https://www.myget.org/F/feedname/api/v2. For the V3 protocol, this URL becomes https://www.myget.org/F/feedname/api/v3/index.json. This feed can be registered in Visual Studio 2015. From the Tools | NuGet Package Manager | Package Manager Settings menu, we can select the Package Sources tab and add a V3 feed in the same way as a V2 feed can be added. We can give the feed a descriptive name, and enter its URL.

Registering MyGet V3 API NuGet

Once added, we can manage packages for our project or solution, and select the newly added feed from the dropdown.

MyGet feed with NuGet V3 API protocol

Does this also work with private (authenticated) feeds?

It’s perfectly possible to consume private (authenticated) feeds on MyGet using the new NuGet client in Visual Studio 2015. Unfortunately there is a bug in the client that makes this a little hard: if it has to prompt for credentials, consuming the feed will fail. The NuGet team confirmed a fix is ready to be released (in fact, an RC version is out), but in the meanwhile a pre-authenticated feed URL can be used to consume a private V3 feed.

A pre-authenticated feed comes in the following format: https://www.myget.org/F/feedname/auth/accesstoken/api/v3/index.json, where the feedname is of course the name of the feed, and accesstoken is one of the access tokens that can be managed via the MyGet website.

Can upstream feeds be proxied?

The MyGet V3 feeds support proxying upstream V2 feeds (not V3 yet). This allows for registering one V3 feed URL in Visual Studio while proxying one or more external (V2) feeds over the same URL. This greatly speeds up working with NuGet! Have a look at our documentation to learn more about feed proxying.

When browsing MyGet, you may notice the V3 feed URL is not being advertised anywhere. The reason for that is twofold: we’re offering the V3 protocol as a preview. We want to make sure the feed behaves the way it should. Second, we want to continue improving V3 protocol support, for example by enhancing support for proxying upstream feeds with upstream V3 sources.

We would love to hear your feedback via @MyGetTeam or through the comments below.

Happy packaging!

Automatically add NuGet, npm and Vsix packages from Visual Studio Online to MyGet

For over a year now, MyGet has had great Visual Studio Online (VSO) integration. We support adding VSO git repositories into build services, running convention-based builds that convert freshly pushed source code into NuGet, npm or Vsix packages. With the Visual Studio 2015 release cycle, Microsoft released a new build system for Visual Studio Online. The artifacts generated from a build can be automatically added to a MyGet feed by adding a Visual Studio Online package source, both from classic XAML-based VSO builds as well as the new build system.

From a MyGet feed, we can use the Package Sources | Add package source | Visual Studio Online build definition button to add a Visual Studio Online build definition. The first time we do this, we’ll have to grant access to our VSO instance.

MyGet Visual Studio build artifact

Once access is granted, MyGet will fetch a list of team projects and their builds. MyGet supports all sorts of build definitions, whether a classic XAML-based build or the new VSO “build vNext”. We can pick the team project we’re interested with, select the build definition, and depending on the VSO subscription we can also choose to post a message to a VSO team room whenever packages from a build are added to MyGet.

Publish NuGet package from Visual Studio Online to MyGet

Once we trigger a build in VSO, whether by checking in code or manually, MyGet will automatically add the generated artifacts to the current feed. Of course, we have to make sure our VSO build produces one or more .nupkg (NuGet), .tgz (npm) or .vsix (Vsix) artifacts (the Publish Build Artifacts build step will be needed for this). To run convention-based builds we can always use MyGet Build Services, too.

We're looking forward to hearing your feedback through the comments below. Or tweet us via @MyGetTeam.

Happy packaging!

Building and packaging NuGet and Npm from BitBucket

A few weeks back, BitBucket launched a new version of their API and web hooks. It comes with a number of changes, but one change we like very much is support for OAuth tokens for pretty much anything, including cloning repositories.

MyGet has had support for building and packaging code from BitBucket for a long time. However up until now we had to ask for credentials in order to be able to clone and build a repository. With the changes introduced in this new API, this is no longer needed! Let's see how we can build a NuGet or npm package from BitBucket without handing our credentials to MyGet.

From an existing (or new) MyGet feed, navigate to Build Services and add a new build source. MyGet supports various sources that provide Git, Mercurial and Subversion repositories. Let's add one from BitBucket.

Before we can see our repositories, we'll have to tell BitBucket that MyGet can access our profile information and a few other things.

Once we have done that, we can pick the repository we want to clone and build. Note that by default MyGet registers a webhook with BitBucket, so that whenever we make a code change and push it to BitBucket, a build is triggered on MyGet. Automatically.

Whether your repository contains a C#, VB.NET or an npm project doesn't matter. The standard conventions will produce a build for many project types. If customization is needed or to have full control over your build, add a build script to do so.

Once a build finishes, we can see the packages it produced. We can test our NuGet, npm or VSIX packages from our MyGet feed. And once we are happy with them we can push them through to NuGet.org or Npmjs.org.

Happy packaging!


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 https://github.com/myget/sample-roslyn-with-vsix)

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 www.myget.org. Next, from the Build Services tab, we can add a GitHub repository as the source. We’ve open-sourced our example at https://github.com/myget/sample-roslyn-with-vsix 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 (https://www.myget.org/F/datetime-analyzer/api/v2). ANd when registering it in Visual Studio (https://www.myget.org/F/datetime-analyzer/vsix/) 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!