Yesterday, the .NET Framework team posted an item announcing service updates to .NET libraries released via NuGet. Please read the full post.
I think this is a very significant announcement because of what it means for Open Source in the .NET Ecosystem. It means you get the best of both worlds for these libraries: Open Source, and commercial security update and rollout. Microsoft has created a way to update vulnerable libraries that you include via NuGet and upgrade any of your customers’ machine if they are affected by a security vulnerability. You, as a developer, get the convenience of NuGet, regular updates, and you keep control over when you upgrade those libraries. But you also get deployment support in ways no other Open Source community manages. If one of the NuGet based libraries you are using is vulnerable, your customers’ machines (servers or clients) will receive the security updates via the normal Windows Update mechanism.
In and of itself, this is a super cool feature. It’s a brilliant innovation. But what it means for the .NET ecosystem is even bigger. Traditionally, the .NET Framework components were all released en masse, with the languages and the Visual Studio IDE. That many dependencies led to longer release cycles. Everyone had to be in sync. Microsoft moved to releasing more .NET Assemblies of band via NuGet. ASP.NET MVC, Entity Framework, SignalR, and WebAPI, to name a few. This does a lot to increase the velocity of releases. But what of the support? For a while, developers needed to watch for updates to any of the libraries they used, and rollout their own patches quickly in the case of any security vulnerabilities. Now, we can enjoy the increased velocity that comes with uncoupling individual components from major releases without incurring the increased risk of being responsible for downloading and applying security patches to every .NET component we use. And, especially, the cost associated with applying those patches to all your customers’ machines.
It’s a well thought out strategy that enables velocity and customer support.
Update: Jonathan Wanagel from the CodePlex team contacted me with a better download URL scheme. See below.
The title says the big news: I added elevate to the NuGet gallery.
Thanks to Phil Haack for helping me get started by writing a great post that makes it easy.
When we loaded the package, we chose to host the package on the elevate download page. That is the only part of the process that’s a bit tricky. When you download the package from CodePlex, you have to accept the license. The link on the download page does not point to the download.
The link on your download page looks like this:
http://elevate.codeplex.com/releases/view/31732#DownloadId=206119 (actual download link for the elevate NuPkg)
That isn’t what you need to register in the NuGet gallery. Instead, you need the link to the binary release. That’s this link:
http://download.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=elevate&DownloadId=206119&FileTime=129415679423400000&Build=17501 (actual Elevate direct download link for the NuPkg.)
If you are uploading your own NuGet package, and the file is hosted on CodePlex, you need to perform a bit of a dance:
As for the current release of Elevate, you’ll notice that we currently have the 0.1 alpha release in the NuGet gallery. Chris is working on a new release, and as soon as that release is ready, we’ll update the version in NuGet.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.