NuPack - Package Management System for the .NET platform Released

NuPack is a free, open source developer focused package management system for the .NET platform intent on simplifying the process of incorporating third party libraries into a .NET application during development.

There are a large number of useful 3rd party open source libraries out there for the .NET platform, but for those not familiar with the OSS ecosystem, it can be a pain to pull these libraries into a project.

NuPack is a free open source package manager that makes it easy for you to find, install, and use .NET libraries in your projects. It works with all .NET project types (including, but not limited to, both ASP.NET Web Forms and ASP.NET MVC).

NuPack enables developers who maintain open source projects (for example, projects like Moq, NHibernate, Ninject, StructureMap, NUnit, Windsor, RhinoMocks, Elmah, etc) to package up their libraries and register them with an online gallery/catalog that is searchable.  The client-side NuPack tools – which include full Visual Studio integration – make it trivial for any .NET developer who wants to use one of these libraries to easily find and install it within the project they are working on.

NuPack handles dependency management between libraries (for example: library1 depends on library2). It also makes it easy to update (and optionally remove) libraries from your projects later. It supports updating web.config files (if a package needs configuration settings). It also allows packages to add PowerShell scripts to a project (for example: scaffold commands). Importantly, NuPack is transparent and clean – and does not install anything at the system level. Instead it is focused on making it easy to manage libraries you use with your projects.

NuPack is itself an open-source project.  The Outercurve Foundation (formerly CodePlex Foundation) today announced the acceptance of the NuPack project to the ASP.NET Open Source Gallery.  Developers - both inside and outside Microsoft – will contribute features, bug fixes and patches to NuPack.

Our goal with NuPack is to make it as simple as possible to integrate open source libraries within .NET projects.  It will be supported in all versions of Visual Studio.  You can start using the first developer preview of it today.

Let’s take ELMAH as an example. It’s a fine error logging utility which has no dependencies on other libraries, but is still a challenge to integrate into a project. These are the steps it takes:

1. Find ELMAH
2. Download the correct zip package.
3. “Unblock” the package.
4. Verify its hash against the one provided by the hosting environment.
5. Unzip the package contents into a specific location in the solution.
6. Add an assembly reference to the assembly.
7. Update web.config with the correct settings which a developer needs to search for.

And this is for a library that has no dependencies. Imagine doing this for NHibernate.Linq which has multiple dependencies each needing similar steps. We can do much better!
NuPack automates all these common and tedious tasks for a package as well as its dependencies. It removes nearly all of the challenges of incorporating a third party open source library into a project’s source tree. Of course, using that library properly is still up to the developer.
Here's a small sampling of what NuPack can do:

To get started using NuPack, you’ll need Visual Studio 2010 installed. NuPack is implemented as a Visual Studio Extension (VSIX). Download the latest release and double click on the NuPack.Tools.vsix file to launch the NuPack Visual Studio Extension Installer.

Launching the Add Package Reference Dialog

There are two ways to interact with the package manager:

• The Add Package Reference Dialog GUI, which gets you started quickly and easily.
• The Powershell based Package Console, for when you need more power and tools.

Let’s start with the Add Package Reference dialog.

1. First, create a new VB.NET or C# application in Visual Studio.

By pure random chance, I’ve chosen to create an ASP.NET MVC 2 application.

2. Right click on the References node within the Solution Explorer and select the Add Package Reference menu option.

This will bring up the Add Package Reference dialog, seen here (click for larger).

The dialog allows you to page through the list of available NuPack packages as well as perform searches against the list of online package. The list of packages is being pulled from an ATOM feed, which can be configured using the Settings button.

Installing a Package

Installing a package is very easy now that we have the dialog up and running.

1. Find the package.

You can either page through the results, or use the search feature. In the Search Online box, type in “elmah”. You should see the following filtered view.

2. Double click the Elmah entry.

That’s it! Behind the scenes, NuPack added the Elmah assembly into a subfolder of your solution, added an assembly reference to that assembly, and also modified your Web.config file with minimal settings to get you started. You’ll probably want to change those settings for a real application.

But you are all set to start using and programming against ELMAH. Visit /elmah.axd within your project to try it out.

Using the Package Console

For those who prefer using the keyboard, NuPack also includes a PowerShell based console for managing packages. The console enables a feature that isn’t available via the Add Package Reference dialog as you’ll see.

To get to the Package Console window, select the View | Other Windows | Package Manager Console menu option.

1. Listing available Packages (List-Package)

Use the List-Package command to list available packages as seen in the screenshot. Note that you get intellisense within the console so if you type List and hit tab, you’ll see a list of options.

This queries the package source and lists the available packages. The nice thing about using PowerShell is that it provides a powerful way of filtering and composing commands. For example, if I only want to list the Id and Description, I can pipe the command to the select command List-Package | select Id, Description

2. Installing a package (Add-Package)

To install a package, run the Add-Package command and specify the Id.

The package will be installed to the default project (specified in the console). You can use the –Project flag to explicitly specify the project.

The console also supplies Intellisense for the package Id.

3. Installing new Console Commands

Earlier, I mentioned that the package console enables a feature that’s not available in the dialog. The feature in question is the ability for a package to contain tools which add new commands to the console.

For example, if you install the prototype Mvc-Scaffold package, a new Add-MvcView command is now available to be called from the console.

This provides a powerful way of extending and automating Visual Studio. In the future, this package might contain commands for completely scaffolding a web application from an object model or a database.

 

Scott Guthrie has posted a good blog on the topic as has Scott Hanselman.

NuPack – Open Source Package Manager for .NET

NuPack is a free open source package manager that makes it easy for you to find, install, and use .NET libraries in your projects. It works with all .NET project types (including, but not limited to, both ASP.NET Web Forms and ASP.NET MVC).

NuPack enables developers who maintain open source projects (for example, projects like Moq, NHibernate, Ninject, StructureMap, NUnit, Windsor, RhinoMocks, Elmah, etc) to package up their libraries and register them with an online gallery/catalog that is searchable.  The client-side NuPack tools – which include full Visual Studio integration – make it trivial for any .NET developer who wants to use one of these libraries to easily find and install it within the project they are working on.

NuPack handles dependency management between libraries (for example: library1 depends on library2). It also makes it easy to update (and optionally remove) libraries from your projects later. It supports updating web.config files (if a package needs configuration settings). It also allows packages to add PowerShell scripts to a project (for example: scaffold commands). Importantly, NuPack is transparent and clean – and does not install anything at the system level. Instead it is focused on making it easy to manage libraries you use with your projects.

NuPack is itself an open-source project.  The Outercurve Foundation (formerly CodePlex Foundation) today announced the acceptance of the NuPack project to the ASP.NET Open Source Gallery.  Developers - both inside and outside Microsoft – will contribute features, bug fixes and patches to NuPack.

Our goal with NuPack is to make it as simple as possible to integrate open source libraries within .NET projects.  It will be supported in all versions of Visual Studio.  You can start using the first developer preview of it today.

A Simple NuPack Scenario – Enabling ELMAH

As a simple example to show off what NuPack enables – let’s assume we are working on a brand new ASP.NET application and want to use the popular open-source “ELMAH” library to log and report errors with our site.  To install ELMAH today, you’d need to manually download it, unzip it, add a reference to your project, make sure you have source control bindings for the library setup correctly, and update the web.config file of your application to include the Elmah HttpModule entries.  All doable – but a little tedious.

With NuPack installed, you can simply open the new “Package Manager Console” that NuPack enables inside VS and type “Add-Package elmah” within it:

Typing "Add-Package elmah” causes NuPack to check an online feed to locate the Elmah library, download it, add a reference of it to your current project, and automatically add the appropriate Elmah registration entries within your application’s web.config file:

And now we have Elmah setup and installed for our project, and error report logging enabled.  No additional manual steps required to make it work.

Learn More About NuPack

Check out the following links to learn more about NuPack and some of the many scenarios it enables:

• Scott Hanselman’s NuPack Tutorial
• Phil Haack’s NuPack Post
• Bill Simser’s Post on NuPack (he is a non-Microsoft dev working on it)
• Rob Reynold’s “Evolution of Package Management on .NET” Post (Rob is one of the leaders of the Nu project and is on the NuPack team)
• David Ebbo’s NuPack Post
• Documentation and tutorials on nupack.codeplex.com

.NET and Open Source

We think NuPack will be a fundamental component of the .NET stack going forward.  It will encourage more .NET developers to use open-source libraries.  Having a standard package manager integrated into millions of copies of Visual Studio will hopefully also encourage the creation of more open source projects with .NET.

 

References

http://nupack.codeplex.com/

http://weblogs.asp.net/scottgu/archive/2010/10/06/announcing-nupack-asp-net-mvc-3-beta-and-webmatrix-beta-2.aspx

http://www.hanselman.com/blog/IntroducingNuPackPackageManagementForNETAnotherPieceOfTheWebStack.aspx

MVC in VB.NET Explained – An Introduction Written So You Can Understand It

If your new to MVC (Model, view, controller) and need a simple yet complete introduction to the topic this is a great article bu Dan Mabbut with About.com. (http://jpda.me/d06VCT).

MVC in VB.NET Explained, An Introduction Written So You Can Understand It.

In the beginning, there was Input-Process-Output. Everything since then is just more details.

That's literally true. The original computer, Eniac, input data about artillery, processed it, and spit out gunnery tables. But they soon learned that it could do so much more. They used it for computations necessary to create the first Hydrogen Bomb. (What would we do without war to underwrite invention?)

The way to understand MVC is to realize that it's just the latest detail on Input-Process-Output. Except that now, it's called Model-View-Controller. Model is Input, View is the Output, and Controller is Process. Sort of. Most authorities recommend that you put your "process" in "Model" and let "Controller" simply act as a switching function. But we're getting ahead of ourselves.

Although I'll be covering the same ground again, I've written several short articles about MVC:

Sorting Through the New Toys - MVC (April 28, 2010)

MVVM - A Fad or The Future? (May 27, 2010)

My new book, Pro ASP.NET 4 in VB 2010 also has a chapter about MVC where much more advanced concepts are explained, such as using MVC to create web pages based on an Entity Data Model generated from a database.

If you're a VB.NET programmer (and I assume that you are), then you now have your mind wrapped around something called the "event driven model". Just like MVC, programming this model depends on having a clear mental image of what the software does automatically and what you have to add. The key to doing MVC is to shift gears to a different mental image. So, let's consider event driven programming for just a second so we can contrast it with MVC.

When you write the standard "Hello World" program using event driven programming, you typically put a Button and a Label on a Form. When the Button is clicked, .NET creates an "event" called the "click event". Your task as a programmer is to anticipate that event and write the code that inserts a String into the Text property of a Label control.

Public Class Form1
    Private Sub Button1_Click(
        ByVal sender As System.Object,
        ByVal e As System.EventArgs
        ) Handles Button1.Click
        Label1.Text = "Hello World"
    End Sub
End Class

The key here is that nothing works unless .NET generates that magical "event" that triggers the execution of your code. MVC is like that. You anticipate things that MVC does and then just insert your code into the right places to make the resulting system do what you want it to do. But you don't code for "events" anymore. (Well ... you can. But then you're working in parallel with MVC. MVC will allow you to insert event driven programming. But that works "on top of MVC" rather than being part of it. When learning MVC, the first thing to do is banish event driven programming from your mind.)

That's why the three circle diagram of MVC is used so much. (I've illustrated the first article linked above with the standard version.) Those three circles are the part that happens "automagically" and where you need to think about putting your code. Unfortunately, it's nowhere near as simple as Windows Forms, as we will see.

To see what the difference is, we're going to code a "Hello World" app using MVC from the ground up. That last part is important. Nearly every other example you will see on the web starts with a runable MVC shell app that is just modified. On the next page, we code an MVC app using the empty app template and add everything we need manually so you can understand what's there and why.

Step 1

You might already have VB.NET 2010 Express fired up and ready to go. Not so fast! Microsoft has chosen not to put any MVC templates in VB.NET Express. Right now, it's exclusively an ASP.NET web technology. So you have to have Visual Web Developer 2010 Express downloaded and fired up instead. (Fortunately, also free.) Or the full Visual Studio 2010 which can do anything.

Fundamentally, MVC is a "design pattern" and you could implement it by simply following the pattern and coding your own classes. I mention this because somebody will inevitably write in and tell me that "we don' need no steekin' templates". (Apologies to Treasure of the Sierra Madre.) Fundamentally, you could also code your own programs with nothing more than the vbc compiler and Notepad, too. We're talking about what's reasonable here.

So fire up Visual Web Developer 2010 Express and select New Project. Under Visual Basic and the Web subheading, you will see two likely templates:

• ASP.NET MVC 2 Web Application



• ASP.NET MVC 2 Empty Web Application

The first one is the one usually used. You can create a new project using that template and run it unchanged to get something like this:

--------

Click here to display the illustration.


--------

There's a lot going on there! And it's all included in the app. Here's the Solution Explorer view of the app:

--------

Click here to display the illustration.


--------

All of the code in those files fit together in an intricate interlocking scheme. Get one parameter out of place and it doesn't run. It's a lot easier to start with an app that already runs and then add, change, and delete to get what you want. But you don't learn as much, so we're going to start with an empty MVC app. When you do that, you get this result:

--------

Click here to display the illustration.


--------

Quite a difference. The error, by the way, is one of the most common ones that you will see as you learn to code using MVC. But all of the necessary pieces are still there. They just don't have the code to fit together anymore. That's what we're going to add. (But I'll still have to sprinkle "programmer pixie dust" in a few places before it will run.)

Step 2

Let's start at the data end: Models. In a realistic business app, the Models folder contains the code to interface with a database or some other source of data. Much of the actual processing takes place in the Models because an underlying philosophy of MVC is complete isolation of function. MVC gurus call this the "Single Responsibility Principal". The other parts of MVC, Controllers and Views, should not know or care where the data comes from. In a real world app, globalization, validation, authorization ... anything necessary to get the data ... will be found here.

In our little "Hello World" app, we only have one piece of data: the string "Hello World!" To add that to the Models folder, right-click the Models folder and add a class named HelloDataModel.vb. Here's the code that goes in this file:

Namespace MVCHelloWorld.Models
    Public Class HelloDataModel
        ' The data: A Hello World string
        Public Property theHello As String = "Hello World!"
    End Class
End Namespace

It looks pretty simple because it's just one class containing one property. But it's not quite that simple because MVC ties together with names and all the names have to be present and match before it works. So, for example, you will find that you use the Namespace keyword a lot. In Windows Forms, you can pretty much ignore it most of the time. In a realistic app, much of the actual work is done by attributes that are used to decorate the classes. For example, in the boilerplate AccountModel file for the non-empty MVC app, the Password property is decorated with four attributes:

<Required()> _
<ValidatePasswordLength()> _
<DataType(DataType.Password)> _
<DisplayName("Password")> _
Public Property Password() As String
...

Often, these attributes have to be supported by other classes that you code. And so on and so on ...

On the next page, we code the heart of MVC, the controller.

Next, let's look at the controller. You can add a file named HelloController.vb to the Controller's folder by right-clicking the Controllers folder and selecting Add. Once you get the boilerplate in place, modify it as shown here:

Namespace MVCHelloWorld.Models
    Public Class HelloController
        Inherits System.Web.Mvc.Controller
        Public Function Greet() As ActionResult
            Dim theHelloGreeting As New HelloDataModel
            ViewData("Message") =
                theHelloGreeting.theHello
            Return View()
        End Function
    End Class
End Namespace

The first thing to notice is that we use the same Namespace that we used in the Models. This won't always be the case. In MVC, things are organized into logical categories using namespaces. You could have several in your program.

The second thing to notice is that this class inherits System.Web.Mvc.Controller. That's where the class gets most of its core functionality. Controllers do things that you won't expect coming from a Windows Forms background because those functions are built into the parent.

And the third thing to notice is that the end product of this class is an ActionResult named Greet. The ActionResult types in the non-empty MVC app are named Index and About. The standard CRUD (Create-Read-Update-Delete) functions are all ActionResults in a real world app. List is an ActionResult. The controller classes usually don't do anything. They just decide what gets done next as a result of what they're passed. This one decides that displaying a greeting should be done next. But it doesn't actually display it. That's done by a view.

Once you have coded the controller, you can also create a view by right-clicking the code in the controller.

--------

Click here to display the illustration.


--------

The Microsoft team has done some good work supporting MVC in their development tools. The linkage between controllers and views is one of the more intricate ways that MVC ties together and they've made it somewhat easier. But the dialog window that is displayed next will still raise a lot of questions if you haven't seen it before.

--------

Click here to display the illustration.


--------

To make things easier, I copied a Master Page from another project and then modified it to remove all the things I wouldn't use. A master page isn't required, but it's a good idea. Here's the page I used:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title><asp:ContentPlaceHolder
    ID="TitleContent" runat="server" /></title>
    <link href="../../Content/Site.css"
    rel="stylesheet" type="text/css" />
</head>

<body>
    <div class="page">
        <div id="main">
            <asp:ContentPlaceHolder
            ID="MainContent" runat="server" />
        </div>
    </div>
</body>
</html>

You can see that things are still linking together by name. For example, you'll see the ID MainContent again in the view, which we consider next.

If you used the dialog to create the view, you will notice that both a Hello folder and a Greet.aspx file in the folder have been added for you. The .aspx files in Views aren't normal .aspx files. For one thing, there is no corresponding .vb code behind file. You don't do any processing in Views, so there is no place to put code. I modified the Greet.aspx file to contain this code:

<%@ Page Title="" Language="VB" 
    MasterPageFile="~/Views/Shared/Site.Master" 
    Inherits="System.Web.Mvc.ViewPage" %>
<asp:Content ID="Content1" 
    ContentPlaceHolderID="MainContent" runat="server">
<h1><%=ViewData("Message") %></h1>
</asp:Content>

The ViewData object is just a keyed dictionary. In this case, Message is the key. It was created in the controller. A lot of MVC purists don't like this technique because (they say) the controller shouldn't be doing any processing. Because MVC is still under active development, and there are lots of other flavors other than the Microsoft brand, you'll see this sort of debate if you start reading about it.

You might think that you're finished now. You might be wrong. There's still more plumbing to put in place and on the next page, we complete the app.

The final code we need is in a file that has been there in other ASP.NET applications, but is used a lot more in MVC: Global.asax. Actually, the code is in the partial code-behind class, Global.asax.vb. (There are also sections added to Web.config to make routing work, but you normally don't have to do anything with them, so you can delay figuring out what they do.) The primary thing that is added to Global.asax is routing. This is a critical part of MVC and defines how incoming browser requests are mapped to particular MVC controller actions. Routing instructions are created in a table when the application is started. The Application_Start() subroutine executes another sub:

RegisterRoutes(RouteTable.Routes)

RegisterRoutes actually builds the table with a series of instructions that are helpfully documented in comments in Global.asax along with the default that is used in the non-empty MVC app:

' MapRoute takes the following parameters, in order:
' (1) Route name
' (2) URL with parameters
' (3) Parameter defaults
routes.MapRoute( _
    "Default", _
    "{controller}/{action}/{id}", _
    New With {.controller = "Home",
              .action = "Index",
              .id = UrlParameter.Optional} _
)

This is why MVC apps don't use normal looking URL's. A typical MVC URL might look like this:

http://myDomain.com/Home/Index/3

The routing table will send this to the Home controller; the Index action; and pass the parameter 3, which is often an index into a database.

Routing instructions in the table are used in sequence. If an earlier table entry satisfies the incoming browser request, then later entries aren't used. You can code these table entries so that multiple requests will "match" table entries for enormous flexibility (and not just a little complexity too). For this reason, you will normally place your routing instructions above the generated entries that are already in Global.asax. In my case, I didn't use a Home controller or an Index action, so I recoded the default this way:

routes.MapRoute(
    "Default", "{controller}/{action}",
    New With {
        .controller = "Hello",
        .action = "Greet"
    })

So for my app, the "Default" url will call Hello.Greet() with this result:

--------

Click here to display the illustration.


--------

Ta-Da!!!

If you think this is a lot of trouble to display "Hello World!" you're right. The main features of MVC do not include simplicity; they include long term application maintainability, flexible design, and efficient execution. (For example, there are no No ViewState and PostBack events clog up the network.) But it does take some getting used to!