The .Net community is beginning to embrace open source software.  For years, we’ve struggled to find a way to elegantly share and use other people’s code – and ultimately leverage billions of lines of code – in a way that fits into our existing toolset and workflow.

NuGet has begun to solve those problems, and now, it’s here in force.

Adoption rate is beginning to grow, new projects are being started with NuGet in the kit and people are beginning to see that there are great gains to make on existing projects as well.

Now It’s Really Real

This morning, NuGet reached a significant milestone, marking it’s official arrival: 1,000,000 package downloads.

Why is this significant?  Well, for starters, it means that it’s no longer just folks messing around. People are using it.  It’s rapidly approaching 2,000 packages and the diversity is good, if not great.  I’ve got three projects already in production that I’ve added packages to – not including dependencies – and I would venture a guess that others have as well.

The hourly downloads have been trending upwards (save a few spikey days).  The 1,000,000 downloads in and of itself isn’t the significant part, but it’s a beacon of what’s happening.

So, what _is_ happening?  Well, as developers on the .Net stack, we’ve finally got a tool that makes reusing code efficient.  We have the ability to consume and update packages (and with the latest version of NuGet we have the ability to define constraints for updates, as well). We can leverage the great work of other devs.  We have open source tools to publish open source libraries, helpers, templates, extensions and more. We can package up pre-configured trials of commercial products, wrap licensing around our content, or give it all away.

Because of all these pieces coming together, we are able to move at our own comfortable pace with no barriers to entry. We can choose to be consumers or contributors to this space.

And NuGet is the critical, now widely-used, cog in the wheel to make it happen.

More to Come

While NuGet is already fantastic in new projects, existing projects that need some love and smaller enterprise projects, it’s tough to get it fully going in enterprise scenarios.  This is the next focus for the folks working on NuGet, and one they’re taking seriously.

Improvements to critical features like NuGet.Server publishing, adding support for authenticated sources, and facilitating CI build products outside the MS domain are all in the works.

Now It’s On You

For anyone who doubts that you can influence this product, you’re wrong in two ways:

1. It’s easy to post problems you run into. If you find something that doesn’t tick the way you like it, post it on the project site. If others are running into the same thing, they will vote on it.  If there’s enough traction, it’ll get promoted to a work item and someone will implement it.
2. You can implement it. If it’s a feature/bug/workflow issue that’s really got you hemmed in, you might as well quit yer bitchin’ and get to work. Fork the source, post the patch and request a pull.  Done.  And then you can go to sleep a less horrible person.

And, once you get into this and you find out how easy it is to share code, you might get the inkling to share some of yours.  It’s free and easy to publish to the NuGet site, and you can do some pretty interesting things with your packages during the execution of you installation or initialization scripts.

Your Turn

There are so many examples out there of great pacakges ready to use for all kinds of project types and scenarios. There is simply no reason for a developer to put off learning how to use this tool, especially because it’s going to take you all of 10 minutes. Folks, that is less time than it will take you to go and find code that you want to use and get it integrated into your project.

Though some folks have been using it for months, others have been hesitant to explore it enough to fully understand what it can do for them. Hopefully, hitting this 1,000,000 package mark will wake them up.

After all, the only effort required to try NuGet in a safe environment is this:

File –> New Project

So, go on. I’ll wait here while you do it.

I received an email from one of the folks at the NuGet talk last night asking about some of the packages we had a look at and I said I’d post a quick list, along with a few others that were handy to have around.

• jQuery, jQuery.UI & jQuery.Validation – these are all in the new MVC3 templates by default, but you can use the Package Manager Console in VS2010 to update them to the latest version (along with the vsdoc file).  You can also easily add them to existing projects.
• EntityFramework (EFCodeFirst) – with the CodeFirst bits now built into EntityFramework we are able to quickly and easily define POCO classes and let the framework do the heavy lifting…kinda like scaffolding for databases.
• Modernizr – old browsers suck, but Modernizr makes them suck a loss less.  It also exposes the presence of all the modern functionality of the client’s browser (missing or not) via boolean values, allowing us to degrade our functionality gracefully.
• Glimpse – What? Client side debugging for ASP.NET MVC? Ohhh yeah. Glimpse lets you dive deep on both sides of the request and response, letting you get a ‘glimpse’ of what happened when you made a call.  Support for MVC, Ajax now, and more coming soon.
• Pluralizer – A simple but elegant solution that lets you contextually set up strings to be pluralized based on the count of the collection you pass it.
• jQuery.ie9ify – Helps you add site pinning features and set up things like notifications, icons and the like.  A must have for installed user bases (like intranets) where you can standardize on a browser, or where your user base is large enough that adding extras for those on IE9 is worth your time. 

Also, Scott Hanselman has started an NPoW – “NuGet Package of the Week” – posting series on his blog. You can check that out here.

Finally, I fielded a couple of questions about init, install and unistall scripts when creating your own packages for NuGet.  Here’s my post on script tips and PowerShell commands commonly used in other packages.

Thanks again all for coming out!  See you June 24th at HTML5 Fest in Winnipeg!

Another great session today with some good questions and some great conversation afterwards.  Thanks peeps!

Here’s some great resources to get you plugged in with NuGet and to help take those first few steps:

• http://www.nuget.org – the official package source
• http://docs.nuget.org – the basics of working with NuGet and creating your own packages
• http://nuget.codeplex.org – the open source code for the NuGet project, as well as key downloads (NuGet.exe and the Package Explorer)

 

You can also follow the NuGet conversation on Twitter (#NuGet), or join in the StackOverflow.com chat room on the subject.

And as always, feel free to send me a note with any questions you may have.

Thanks!

You know a conference is going well when you the connections start happening faster than you can manage to keep up with them.  There were a lot of great people at the session today and a lot of great conversation afterwards.

Thanks to all who attended!  I’ll be doing another session tomorrow on NuGet and will post back here with all the critical links.

If you’re looking to get started, make sure you check out this post I did with a ton of material for ASP.NET MVC.

Also, for those of you who were excited about the MvcScaffolding bits, be sure to check out my Joyride post on the same.

See you tomorrow!

So what do you do when you have a room full of people and your presentation goes awry? Make sure you know your domain before you go in.

I just finished my talk on the spanky, fun Asp.Net Mvc Framework, and I thought I’d prepared well prior to going in.  Aside from a few minor snags – also called teaching opportunities   – things ran rather smoothly and the initial feedback on the session was quite positive.  Running into errors and exceptions is okay, in my mind. We’re programmers after all and 90% of what we do is wrong ;o)  I’ve been through most scenarios, especially in this stack, and so I know how to respond.

But then it hit me: a curve ball from the audience (thanks for the questions by the way!) took me a little off course (which I love) and I tried to figure out what the problem was (which, completely topical to my talk, was scary).  And, after all, it’s important to know what color scary things are so that you can identify them easier. 

Sad face here: I hit an exception I hadn’t seen before.  On stage. In front of 50 awesomely patient folks.  sigh

That image reads:

Model compatibility cannot be checked because the database does not contain model metadata. Ensure that IncludeMetadataConvention has been added to the DbModelBuilder conventions.

Unfortunately I was a little too nervous to tackle it beyond a couple of quick attempts, but the solution was quite simple: drop the database and let the EntityFramework recreate it.

What Went Wrong

I think the biggest issue was that I was playing with multiple changes to the model classes during the presentation.  The metadata associated with the database, stored in its own table where the db is created, got out of sync with what was in the database and what was in the classes in the project.  Not a biggy, but frustrating just the same.

I will note again that this isn’t something you’d likely run into late in a project, only early on.

Thankfully at the front end of a project we are okay with dropping data, especially when we’re working with something like EF Code First…if we really want data in those tables after we make changes we can easily create our own db initializer and add seed data.

Hopefully, when you run into this kind of error, you won’t be on stage. ;o)  At least, not without having first read this post.

Update Via Twitter

I received a message from one of the awesome NuGet folks on Twitter about this post on NuGet real world scenarios:

[](http://oldblog.jameschambers.com/Media/Default/Windows-Live-Writer/Oh-Yes-NuGet-Can_9855/image%5B6%5D_2.png)

David is pointing out that if you want to upgrade a package you can first remove its dependencies, which allows you to do so without NuGet unwinding the operation. Thanks to David for this!

I responded by saying I’d still like a –ForceUpdate command that would bring all dependencies to the correct version (known as leveling) and have since discovered that such a feature is in the works for NuGet. 

More good things to come for sure.