MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

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!

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!

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!

Black Friday Sales - 30% discount on MyGet Starter and Professional

Thank you! Black Friday dealsWhile in Europe we don’t have holidays this week, we do want to share the tradition of Thanksgiving. MyGet could have never grown into what it is today without you. We'd like to thank you by having a sale on our Starter and Professional plans!

Starter and Professional Subscriptions of 6 months get a 15% discount. If you decide to stay with us for a full year, we’ll give you 30% off!

Interested? Sign in to your MyGet account and create a new subscription or extend your existing one.

Since today is “Black Friday” and right after the weekend is “Cyber Monday”, we’re keeping this sale available until Tuesday December 2nd, 2014. This gives ample opportunity to purchase a MyGet subscription at a discounted rate.

Happy packaging!

PS: Give our new features a try, too. We have service messages support, more web hooks and a load of other things!

Could not load file or assembly… NuGet Assembly Redirects

When working in larger projects, you will sometimes encounter errors similar to this one: “Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.” Or how about this one? “System.IO.FileLoadException : Could not load file or assembly 'Moq, Version=3.1.416.3, Culture=neutral, PublicKeyToken=69f491c39445e920' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Search all you want, most things you find on the Internet are from the pre-NuGet era and don’t really help. What now? In this post, let’s go over why this error sometimes happens. And I’ll end with a beautiful little trick that fixes this issue when you encounter it. Let’s go!

Redirecting Assembly Versions

In 90% of the cases, the errors mentioned earlier are caused by faulty assembly redirects. What are those, you ask? A long answer is on MSDN, a short answer is that assembly redirects let us trick .NET into believing that assembly A is actually assembly B. Or in other words, we can tell .NET to work with Newtonsoft.Json 6.0.0.4 whenever any other reference requires an older version of Newtonsoft.Json.

Assembly redirects are often created by NuGet, to solve versioning issues. Here’s an example which I took from an application’s Web.config:

<?xml version="1.0" encoding="utf-8"?> <configuration> <!-- ... --> <runtime> <legacyHMACWarning enabled="0" /> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" /> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

When running an application with this config file, it will trick any assembly that wants to use any version < 6.0.0.0 of Newtonsoft.Json into working with the latest 6.0.0.0 version. Neat, as it solves dependency hell where two assemblies require a different version of a common assembly dependency. But… does it solve that?

NuGet and Assembly Redirects

The cool thing about NuGet is that it auto-detects whenever assembly redirects are needed, and adds them to the Web.config or App.config file of your project. However, this not always works well. Sometimes, old binding redirects are not removed. Sometimes, none are added at all. Resulting in fine errors like the ones I opened this post with. At compile time. Or worse! When running the application.

One way of solving this is manually checking all binding redirects in all configuration files you have in your project, checking assembly versions and so on. But here comes the trick: we can let NuGet do this for us!

All we have to do is this:

  1. From any .config file, remove the <assemblyBinding> element and its child elements. In other words: strip your app from assembly binding redirects.
  2. Open the Package Manager Console in Visual Studio. This can be done from the View | Other Windows | Package Manager Console menu.
  3. Type this one, magical command that solves it all: Get-Project -All | Add-BindingRedirect. I repeat: Get-Project -All | Add-BindingRedirect

NuGet Add Binding Redirect

NuGet will get all projects and for every project, add the correct assembly binding redirects again. Compile, run, and continue your day without rage. Enjoy!

PS: For the other cases where this trick does not help, check Damir Dobric’s post on troubleshooting NuGet references.

MyGet feeds now support Target Framework Filtering

On October 1st, the NuGet team enabled Target Framework Filtering in NuGet.org's Search API. We're happy to announce we've just flipped the switch in our back-end to enable this on MyGet feeds as well! Ever since version 2.1, the NuGet clients have been sending the consuming project's target framework in the search requests. Everyone who's using NuGet 2.1 or above is going to benefit from this server-side optimization.

What does this mean for you as a package consumer?

Since NuGet will now be filtering package search results by target framework, in a nutshell, you should no longer see this dialog when installing packages:

More details about this feature can be found on the NuGet blog.

I'm using upstream package sources. Does anything change?

Yes and no. Upstream package sources that support target framework filtering, like NuGet.org and MyGet.org, may return different (but better) results from what was returned previously. For other package sources, we will return search results the way we did before.

If the clients were sending this information to the server since v2.1, what took you so long?

We want MyGet feeds to be fully compatible with the NuGet API that lives at www.nuget.org. This means we want MyGet to provide a consistent behavior from a user/client perspective.

Happy packaging!

Notifications let you know when a package is updated

Call it human nature, but whenever an update to a software package is available we want to know about it and install it immediately. We do this with our computer, phone and even our NuGet packages. For good reason! The packages we depend upon may be updated because of bug or security fixes and even new features we want to make use of.

MyGet already supported automatically updating NuGet packages from upstream package sources, however we felt that this might not always be the best solution for all scenarios. We’ve now made it possible to receive e-mail notifications about package updates instead, allowing you to decide manually if you want to upgrade or not.

Update notifications per e-mail

E-mail notifications can be enabled from your feed’s Package Sources settings, editing the upstream package source configuring which actions should be performed and when.

NuGet update notifications

We will send you an e-mail (or perform an automatic update, or both) at the chosen interval. This helps you keep up-to-date and allows for an easy update of the package: after clicking a link in the e-mail, MyGet will show what the latest available version is and offers a one-click install.

Latest available NuGet package version

Happy packaging!

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!

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!