MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

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.

Build Services - Introducing pre- and post-build steps

With our 1.9.5 release out of the door, we’ve introduced support for pre- and post-build steps in MyGet Build Services. When using batch / PowerShell based builds for building your GitHub, BitBucket or Visual Studio Online projects and making NuGet packages for them, MyGet Build Services will scan for batch files to be executed. In addition to the default build.bat (or .cmd or .ps1), we search for pre- and post-build steps as well. These can be batch scripts or PowerShell scripts that are run before and after the actual build file.

When using MyGet Service Messages in the build, pre- and post-build steps can be used to prepare the build environment by setting the correct package version number, or creating additional environment variables for use by the build script.

More information can be found in our docs.

Happy packaging!

Build Services supports Service Messages

Service messages for MyGetWe’ve just deployed support for service messages in MyGet Build Services. With them, you can interact with our build agent by simply writing a message to the build output. This makes it easy to work with them from any build framework used, be it a simple batch file, PSAKE, MSBuild or others.

But what can you do with them? Why are they useful? There are a couple of situations that come to mind:

A service message looks like this: ##myget[buildNumber '1.0.0-beta1']. We also support a subset of TeamCity service messages. This makes your builds more portable between build systems and gives you more control of the build process. More information is available from our documentation.

Happy building, and happy packaging!

Web hooks released - Integrate MyGet with other services

A few weeks back, we announced the preview of MyGet web hooks. Today, we’re happy to say we’ve released web hooks for all our users. With web hooks, your feeds can communicate with external services whenever a specific action occurs on the feed. Events can be posted to your web server, e-mail, Twilio, Twitter, Visual Studio Online Team Rooms, HipChat and Slack.

Web hook types

Webhooks can be used to perform actions based on an event, for example sending out a tweet when a package is pushed or updating an issue tracker when a build succeeds. We’ve blogged some demos, for example on how to strong-name sign packages when added to a feed and how to implement custom retention policies. It’s not always required to write custom code though: we integrate with a variety of services such as Twitter, Twilio, HipChat and starting today, with Visual Studio Online Team Rooms and Slack.

Slack integration with MyGet

Only feed owners and co-owners can manage webhooks for a feed. Each webhook can be triggered for one or more event types, depending on the implementation. Webhook deliveries can be inspected, including full logs, as well as redelivered in case this is needed. Give web hooks a go!

Happy packaging!

MyGet 1.9.5 Release Notes

MyGet 1.9.5 was released on November 18, 2014.

Major Features

It's been a while since we tagged another MyGet release, but here we are, 9 months after tagging v1.9.0. We constantly ship and deploy improvements to our service so this v1.9.5 basically aggregates everything we've done since then, combined into a single milestone. This release contains many exciting new features. We'd love to hear from you so please send us your feedback

MyGet

MyGet Enterprise

MyGet Build Services

Minor Tweaks and Bug Fixes

  • Build Services: Builds now fail immediately for feeds that return a 4XX or 5XX status code
  • Build Services: No longer ignore *Test*.nuspec files when packaging
  • Build Services: Assembly Version Patching no longer fails to process files that contain Visual Studio regions
  • Build Services: Delete web hook at GitHub / VSO when build source is deleted
  • API: nuget delete is no longer case-sensitive on package ID
  • Cloning gallery feeds now unpublishes the cloned feed from the gallery
  • Allow updating the description of access tokens
  • Support page - Ability to select the (own) feed related to the support request, which helps us provide even faster support! ;)

In addition, this release also contains a lot of performance fixes, and we continue to work hard on improving your overall MyGet experience. If you feel strong about a missing feature or have an idea for further improvement, please let us know! We build this for you!

Happy packaging!