×

First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

Yesterday there was quite a buzz around something Microsoft just released called “NuPack” which is described as:

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.

It’s a pretty cool mechanism for getting .NET libraries.  For other open source developers this concept isn’t something new (i.e., gems).  But for .NET developers it might be because it is a difference from the way we typically have received dependent and 3rd party assemblies for our projects.  It provides a PowerShell script mechanism for adding packages as well as the well-known “Add Reference” gesture for VS developers.

All the initial information around NuPack has been from folks like Scott Guthrie, Phil Haack, David Ebbo, etc.  You might recognize these names from the ASP.NET world.  In fact if you do your first “list-package” command you’ll see a lot of ASP.NET-related packages.  If you didn’t know any better and weren’t an ASP.NET developer you might ignore this.  However, NuPack is for everyone!

One of the most commonly installed items for Silverlight developers after the toolset is the Silverlight Toolkit.  It is a plethora of controls that frankly you probably can’t live without (at least one of them) if you are developing a broad Silverlight application.  After spending a few minutes reading on NuPack I decided to explore.

My initial playground – Building the MyNuLibrary package

I first just wanted to play around and created a Silverlight class library MyNuLibrary.  It has one class Math that just has two functions.  The contents is pretty much irrelevant here.  I wanted to create a package for this and test it out.

In my project structure I decided to put the tools in the project.  To be clear, this felt completely wrong.  My “tools” shouldn’t be a part of my project.  I think this will be resolved with better build task integration, but for now to create a package you need the NuPack.exe tool.  I put that and NuPack.Core.dll in a Tools folder in my project.  I then created my manifest (MyNuLibrary.nuspec) file as follows and put it in the root of my project (marking the build action as None of course):

   1: <?xml version="1.0" encoding="utf-8"?>
   2: <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
   3:     <metadata>
   4:         <id>MyNuLibrary</id>
   5:         <version>1.4</version>
   6:         <authors>
   7:             <author>Tim Heuer</author>
   8:         </authors>
   9:         <language>en-US</language>
  10:         <description>Custom Silvelright Math library</description>
  11:     </metadata>
  12:     <files src="bin\debug\MyNuLibrary.dll" target="lib\SL4" />
  13: </package>

You can see that the <files/> node tells the package where to put things.  Notice the lib\SL4 target attribute value.  This tells NuPack (and installers of the package) that this library is really targeting Silverlight 4 (uses TargetFramework value of the source project when installing the package to verify).  There is more information on the NuPack project site about this.

Since my tools were relative to the root I needed to provide the bin\debug path in the source attribute value.  Initially this caused me problems as the NuPack.exe unmodified then bundled them into lib\SL4\bin\debug\MyNuLibrary.dll path.  When installing (using add-package) it failed because it said it couldn’t find any assembly that would match my project.  Apparently right now NuPack expects binaries to be in the framework folders, but not in tree structure.  For me, I modified PathResolver (in NuPack.Core):

   1: if (actualPath.StartsWith(basePath, StringComparison.OrdinalIgnoreCase))
   2:     {
   3:         //packagePath = actualPath.Substring(basePath.Length).TrimStart(Path.DirectorySeparatorChar);
   4:         packagePath = Path.GetFileName(actualPath);
   5:     }
   6:     else
   7:     {
   8:         packagePath = Path.GetFileName(actualPath);
   9: }

for my needs.  I’ve communicated the issue to some folks on the NuPack core team and I think there may be some changes (I haven’t submitted a patch yet until I understand the need for the original code path).  And yes, I realize my change above effectively makes the if…else do the same thing and thus the if…else isn’t needed.  Again, I’m awaiting confirmation of the valid scenarios before submitting what I think the patch should be.

All that aside, I then added a post-build event to my project (note I added quoted params here which is not in the CodePlex documentation sample – if you don’t use quotes and you have spaces in your paths, then your post-build will fail…adding the quotes saves you time):

   1: "$(ProjectDir)Tools\NuPack.exe" "$(ProjectDir)MyNuLibrary.nspec"

And upon build I now have a MyNuLibrary.1.4.nupkg file as an artifact of my build.  Done!  If we look at the contents (it’s actually just a OPC ZIP file we can see the structure and you’ll notice that our binary is in the lib\SL4 folder.

Surfacing MyNuLibrary package

The next step is to have your package visible somewhere.  The NuPack VS shell and the Add Reference dialog can recognize 2 types of paths: an Atom feed or a local directory.  For testing I just used a local directory using the settings in VS:

NuPack source locations

And then when I run list-package it shows only my packages from that “feed”:

NuPack list-package output

Now I can consume it.

Consuming MyNuLibrary package

Now I can start a new Silverlight project and open up the VS Package Window and initiate a command to add the package.  I call add-package MyNuLibrary and see that my Silverlight project gets the reference automatically included in my project (and the literal binary is placed alongside my solution for the reference path):

NuPack consuming add-package

And I’m done.  Pretty cool.  Any updates I (as the library author) would just update my .nuspec file to the new version, generate a new package, and publish it again.  The app developer can initiate update-package MyNuLibrary and get the updated bits.

Real world – Silverlight Toolkits

While my above exercise was interesting and demonstrated that NuPack could be used for Silverlight projects as well (ahem, SilverlightContrib) I thought I’d explore a more useful sample.  I took the Silverlight Toolkit binaries and packaged them up for NuPack.  Here was my manifest:

   1: <?xml version="1.0" encoding="utf-8"?>
   2: <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
   3:     <metadata>
   4:         <id>SilverlightToolkit</id>
   5:         <version>4.0.40413.2020</version>
   6:         <authors>
   7:             <author>Microsoft</author>
   8:         </authors>
   9:         <language>en-US</language>
  10:         <description>Silverlight Toolkit providing a set of controls</description>
  11:     </metadata>
  12:     <files src="Binaries\System.Windows.Controls.Toolkit.dll" target="lib\SL4" />
  13:     <files src="Binaries\System.Windows.Controls.Input.Toolkit.dll" target="lib\SL4" />
  14:     <files src="Binaries\System.Windows.Controls.Layout.Toolkit.dll" target="lib\SL4" />
  15:     <files src="Binaries\System.Windows.Controls.Data.Toolkit.dll" target="lib\SL4" />
  16:     <files src="Binaries\System.Windows.Controls.DataVisualization.Toolkit.dll" target="lib\SL4" />
  17: </package>

Since the source code is available for the toolkit I just used that base (hence the “Binaries”) folder name in the manifest.

The end result is me being able to include the Silverlight Toolkit and referencing it in one step rather than downloading, installing the MSI, and adding references.  Here’s a quick video of how simple that was:

Get Microsoft Silverlight

Awesome huh?  Now I could (and probably should have) actually made these independent packages so you could only get the Visualizations if you didn’t need anything else…and then could use the dependency feature of NuPack if needed.

Notice how I also did the Silverlight for Windows Phone Toolkit as well and that it automatically added the Icons for the ApplicationBar in my project as well.  That was due to a helpful tip from Phil about naming conventions in the package.

Summary

I think NuPack is pretty cool  Yes, flame away that it is nothing new conceptually.  That’s fine.  However the interation into the tool I use most is great and that I don’t have to go to a different console window and then back and forth.  That level of integration is pretty slick.

Will the Silverlight Toolkit(s) be deployed like this?  Who knows, right now it is just an experiment.  But it was pretty cool to see it all working as expected.  I think for an alpha view of the process it’s pretty good.  Oh and if you want IntelliSense on the nuspec file, they’ve published the schema so you can put that in a text file (nuspec.xsd) and place it in your %ProgramFiles%\Microsoft Visual Studio 10.0\Xml\Schemas directory.  Then notice my xmlns that I have in the snippets above?  Adding that will give you IntelliSense on the file format.

Hope this helps!


This work is licensed under a Creative Commons Attribution By license.


10/7/2010 11:42 PM | # re: Deploying Silverlight assemblies via NuPack
Sounds great..
Now we're on the Silverlight Toolkit subject: it's very quiet!
How about a new version (e.g fixing dragdrop bugs)?
Is primary focus on Windows Phone?
10/26/2010 4:08 AM | # re: Deploying Silverlight assemblies via NuPack
Just another copy of an apache project. Maven, this time.
Gravatar
10/29/2010 6:12 PM | # re: Deploying Silverlight assemblies via NuPack
Kernighan, I'm not sure he stated it as being anything other than a port of a good idea. But you say 'just' like the idea wasn't fantastic to begin with. You really shouldn't discredit really good ideas of other communities. We should really be embracing and implementing the good ideas of other communities. At the same time listening to the voices of those communities, in terms of their dislikes and likes of the implementation.

My real concern is this project will be overlooked in general because of the sentiment of people like you. Oh it's just another... no this is a really good step in the right direction. Enough said. This is an idea that needs to be fostered and supported. If you're not convinced of the merits of such a project, ask a Ruby developer if they could imagine Ruby development without gems because we are questioning the merits of such a project as a community. Their reply will most likely be, 'ahhh.. you don't have that yet? You have to do what with an .msi file, you have to be kidding?'.

No longer will this be our way... soon... very soon.. muahahaha.. sorry the evil laugh just felt right.
1/13/2011 12:55 PM | # re: Deploying Silverlight assemblies via NuPack
Fantastic reading, thanks alot.
7/10/2011 3:20 PM | # re: Deploying Silverlight assemblies via NuPack
I am working on a project web management and I think this feature can be very helpful for me. Silverlight has a great flexibility towards networking and database features. Our project includes how to cache website visitors at any specific time. Thanks
7/20/2011 3:28 AM | # re: Deploying Silverlight assemblies via NuPack
I had to thank you for your time to learn facebook status this excellent! Really have fun with every bit of it and I've bookmarked to check out what's new in your blog post.
8/29/2011 11:03 PM | # re: Deploying Silverlight assemblies via NuPack
there was quite a buzz around something Microsoft just released called “ NuPack ” which is described as: NuPack is a free open source package manager that makes it easy for you to find, install, and use .NET libraries in your projects Web
10/11/2011 12:03 PM | # re: Deploying Silverlight assemblies via NuPack
Thanks for introducing nupack to silverlight, there are many interesting possibilities with this mighty duo.
- Telpu uzkopšana
10/18/2011 6:11 AM | # re: Deploying Silverlight assemblies via NuPack
Google has released its new Books API in CodeLabs that allows the developers to write Applications and query the books which are searchable on books.google.com which includes the metadata , pricing and many more . Banquetes
5/28/2012 7:41 AM | # re: Deploying Silverlight assemblies via NuPack
As for me, your post is very interesting and important. Thanks! <a href="http://beauty-cosmetology-careers.com> beauty and cosmetology careers
10/19/2012 2:36 AM | # re: Deploying Silverlight assemblies via NuPack
I think Say Yes to Education is a great thing. The graduation gap is by no means of measure that inner-city kids are not as smart as suburban kids. It has been shown many times that they just don't receive the same breaks or opportunities as their peers from better off families. All these kids deserve the same chance to succeed so that their true talent will determine who is more successful, not just who got more opportunities.
10/19/2012 8:29 PM | # re: Deploying Silverlight assemblies via NuPack
Ryan: Yes, that's something that may cause trouble. Especially when moving a project to a server with another culture setting. One way to work around this problem would be to use CurrencyDecimalSeparator property for the current culture instead of the . in the expression. More info at msdn.microsoft.com/...
11/10/2012 6:18 PM | # 
I was extremely pleased to find this site. I wanted to thank you for your time just for this wonderful read!! I definitely loved every little kinh mat bit of it and I have you saved as a favorite to check out new stuff on your website.

 
Please add 2 and 7 and type the answer here:

DISCLAIMER:

The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.