Rob Reynolds - The Fervent Coder

Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version

Rob Reynolds — Wed, 25 Jan 2012 16:29:19 GMT

As software creators we don't get to decide what version of our tools / libraries that people use. If we try to force them, our users will go somewhere else.

Update: What Type of Software This Applies To

This post talks of tools, applications and libraries. Things that end up in the users hands. This does not apply to SaaS or websites. These do not end up in the hands of the users in the same sense.

For those of you who immediately think of Chrome or Firefox, which are applications that end up in the users hands, those apply to this post as well. They have nearly perfected a silent upgrade experience, but if they ever mess up that experience, users can choose to use something else. And I believe there is a way to opt out as well (not easily achieved but possible).

Software Release Management

I write software. Much of it is open source. I have multiple versions of my products out there. Even with newer versions available that fix bugs and bring about new features, I still find people using older versions. Even though I have a better newer version that fixes some of the bugs they are dealing with, they are still using an older version. Think about that for a second. There must be a good reason right? Let’s state this in an official sense.

As a software creator you release software. You put a release out there and people use that release. You delineate different releases by a concept of versioning. People use a particular version of your release. You release newer versions of your software that has fixes and enhancements. You hope users upgrade to the latest release when it is available.

I’ve stated five facts and finished with a hope. If you can accept those as facts, we can move on. If we can’t, then you might want to stop reading now because we are never going to agree. If you are a developer like me, you really want people to always use the latest version of your software, so you might be able to accept the last statement as a fact for you. I really want people to always use the latest release of my software as I have went through the trouble of testing it and making it better.

Now let me change some terms for you. Software release management is really a fancy way of saying package management. A software release could be better termed a package. So to restate, as a software creator, you release packages. You put a package out there and people use that package. You delineate different packages by a concept of versioning. People use a particular version of your package. You release newer versions of your package that has fixes and enhancements. You hope users upgrade to the latest package when it is available.

The Hope Versus The Force

I say “hope they upgrade” because you really can’t control that aspect. You can try. You can delete the older versions. You can refuse to have older versions available. You can tell users that they should and need to upgrade. But you put it out there once and it is now out there forever. People will find a way to get to the particular version they need. Or they will go elsewhere. Users speak with their feet.

I find attempting to force a user to do something is both an exercise in futility and a great way to guarantee that you have less users overall.

So people must want to use a particular version of a product. Let’s examine this a little more. Why on earth would someone use an older version of a product when a newer, better, less buggier version is available?

Why Do Users Use Older Versions?

Users use older versions of our packages and they have great fundamental reasons for doing so:

It reduces their risk.
It guarantees that users of their library (that has a dependency on your library) have a good experience.
It guarantees that the product that they have tested is the same product that gets into the hands of consumers.
It guarantee their product builds successfully and the same way each time.

In fixing a product and making it better and less buggier, you may actually be breaking someone’s ability to use a newer version. And you have no guarantee to the user that this version doesn’t have flaws of it’s own. Right? Otherwise there would only be one version that ever had fixes in it. We wouldn’t need to release newer versions with fixes, only enhancements. But we don’t. We fix things we thought worked and we fix things we tested but missed some crazy edge case. This is why we go down this path of release management. This is software development.

So people get a certain version and they use it. Users upgrade to the latest version of software when they are ready, not when the software creator is ready. People depend on certain versions or on a range of versions. In reality I can't force someone to use the latest version. If I try, they will find the version they need through the powers of the internet or find another way. Accepting that, I can give them a way to see it and help them fall into the pit of success.

From the User Perspective

Shifting to the perspective of the user, I might use your library in my own software. Being able to build my product, even if it means it is using an older version of your package that has bugs, is worlds more important to me and my users. We'll get to your latest version when we can test that it doesn't break our product. But don't try to force me to upgrade to your latest version or I will find another way. I'm not saying that with your package but in all packages the newer version may be buggier than the current buggy version we are using. We don't know and you can’t guarantee that it doesn’t, even with extensive testing. Testing doesn’t prove the absence of bugs, only the absence of errors that you know. I digress.

It’s an evil that we know versus and evil that we don’t. Or put another way, it's a buggy version we know versus a buggy version we don't.

If it’s a tool, we need to ensure that our usage of your product still meets our expectations. We need to test it even though you did and make sure it still works for our needs and scenarios. Where it doesn’t we need to decide if that means we can shift our expectations and upgrade. But we are not going to blindly upgrade and just use the latest version because the software creator believes that is best.

Can you cover the millions of dollars that we might lose by taking on a newer version of your product? If you can give me that guarantee, as a user I will gladly pass that risk on to you.

Final Thoughts

Whether you agree or not, as software creators we don't get to decide what version of our tools / libraries that people use. We just don’t have that luxury. If we try to our users will go somewhere else. So we make it easy for them to upgrade so they will want to. We make the upgrade experience painless so they will want to. We need to be good stewards.

DropkicK–Deploy Fluently

Rob Reynolds — Sun, 23 Oct 2011 15:52:38 GMT

DropkicK (DK) has been in development for over two years and has been used for production deployments for over a year. Dru Sellers originally posted about DK back in 2009. While DK isn’t yet as super easy to grok as some of the other ChuckNorrisFramework tools and offers little in the idea of conventions, it is still a stellar framework to use for deployments.

DK works well in environments where you know all of the environments you will deploy to ahead of time (although not required due to the ability to pull in JSON settings files and servermaps). It is not for every environment, as DK will need to be able to get to the remote location through UNC (if deployed from a local server everytime it won’t be an issue) except for the database. DK is continually improving, so expect a transition into adding FTP type deployments as well.

I am going to stay somewhat introductory, so you won’t see this post get too detailed into exactly how you can use DK for deployments. That would be best covered by reading the wiki and looking at examples or a series of articles.

Concepts of Kicking Your Code Out with DropkicK

Deployment Step – The simplest concept of execution of deployment. This is a step that is involved with getting something set up during a deployment. This could be copying files or setting a folder permission.

Deployment Task – This is a collection of one or more steps to do in making something happen during the deployment. Say a task is to copy some files. A step in that task might be to clean/clear folders. Another step is to remove read only attributes. The last step in that is to actually copy files/folders. This is nearly synonymous with the concept of deployment steps and often referred to that way, even by the maintainers of DK.

Deployment Role – A role is a collection of tasks that as an atomic unit have set up a particular area of a deployment. Like a database. Or a Web site. A role contains one or more deployment tasks.

Deployment Plan – This is a collection of all roles for making a deployment happen. This is what you write when you sit down to write a dropkick deployment for your code.

Deployment Settings – These are settings you can draw from in any deployment step. A core concept to DK is the idea of environments and is baked into all settings.

Deployment JSON Settings – This is the equivalent of the deployment settings, with the actual values that you want the deployment settings to get at run time. This is separate so that you can make changes in case you need to make changes prior to deployment.

Deployment Server – A deployment role is targeted against one or more servers.

Deployment ServerMaps – This is the physical server or servers that you want to target Deployment Roles to for a particular environment. Each role you want to deploy will need at least one physical location.

Remote Execution – When certain tasks must be run against the server they are targeting, DK will copy over an executable to a known location on that machine, run it through WMI on that particular machine, wait for it to finish, and then bring the execution log back to the main logs. This means you do not need a service installed on the remote machine for installation.

Deployment Logs – DK has a few logs that it puts together during the deployment. The one you see in the console is a summary of what is happening. There is a run log that contains details of everything that is happening. There is also a db log, a security log, and a file change log. These logs can be passed to each party that cares about them after a deployment for auditing sake.

NuGet Install

If you want to get a quick start on seeing a good example of DK, just pull in the dropkick nuget package and it will bring some sample code.

Running DropkicK

DropkicK expects you to tell it where the deployment DLL file is, what environment it is deploying to, what roles it is deploying, and where the deployment settings files are located. It runs in trace mode by default, determining if one can actually execute the deployment plan (has permissions, servers exist, etc).

The syntax for running dropkick is:

dk.exe [command] /environment:ENVIRONMENT_NAME [/ARG_NAME:VALUE] [--SWITCH_NAME]

At a minimum you can run dropkick with dk.exe execute. This will deploy all roles to ‘LOCAL’ environment with ‘Deployment.dll’ (seated next to dk.exe) looking for ‘.\settings\LOCAL.servermaps’ and ‘.\settings\LOCAL.js’

dk.exe execute /deployment:..\deployments\somename.deployment.dll /environment:LOCAL /settings:..\settings /roles:Web,Host

The above should give you an idea of all of the options you can pass to DK for execution.

You can pass a silent switch to DK to allow for completely silent deployments. Although rough at the moment, there is a wiki article for deploying from TeamCity. That can be found here: https://github.com/chucknorris/dropkick/wiki/TeamCityIntegration

Enough Talk - Show Me the Code!

The below code shows an example deployment plan for executing a deployment to Db, Web, and Host roles. It leaves out the Virtual Directory setup, but that can be easily brought in from looking at an example (https://github.com/chucknorris/dropkick/blob/master/product/dropkick.tests/TestObjects/IisTestDeploy.cs).

using System.IO;
using System.Security.Cryptography.X509Certificates;
using dropkick.Configuration.Dsl;
using dropkick.Configuration.Dsl.Files;
using dropkick.Configuration.Dsl.Iis;
using dropkick.Configuration.Dsl.RoundhousE;
using dropkick.Configuration.Dsl.Security;
using dropkick.Configuration.Dsl.WinService;
using dropkick.Wmi;

namespace App.Deployment
{
public class TheDeployment : Deployment<TheDeployment, DeploymentSettings>
{
  public TheDeployment()
  {
      Define(settings =>
      {
          DeploymentStepsFor(Db,
                             s =>
                             {
                                 s.RoundhousE()
                                     .ForEnvironment(settings.Environment)
                                     .OnDatabase(settings.DbName)
                                     .WithScriptsFolder(settings.DbSqlFilesPath)
                                     .WithDatabaseRecoveryMode(settings.DbRecoveryMode)
                                     .WithRestorePath(settings.DbRestorePath)
                                     .WithRepositoryPath("https://github.com/chucknorris/roundhouse.git")
                                     .WithVersionFile("_BuildInfo.xml")
                                     .WithRoundhousEMode(settings.RoundhousEMode);
                             });

          DeploymentStepsFor(Web,
                             s =>
                             {
                                 s.CopyDirectory(@"..\_PublishedWebSites\WebName").To(@"{{WebsitePath}}").DeleteDestinationBeforeDeploying();

                                 s.CopyFile(@"..\environment.files\{{Environment}}\{{Environment}}.web.config").ToDirectory(@"{{WebsitePath}}").RenameTo(@"web.config");

                                 s.Security(securityOptions =>
                                 {
                                     securityOptions.ForPath(settings.WebsitePath, fileSecurityConfig => fileSecurityConfig.GrantRead(settings.WebUserName));
                                     securityOptions.ForPath(Path.Combine(settings.HostServicePath, "logs"), fs => fs.GrantReadWrite(settings.WebUserName));
                                     securityOptions.ForPath(@"~\C$\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files", fs => fs.GrantReadWrite(settings.WebUserName));
                                     if (Directory.Exists(@"~\C$\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files"))
                                     {
                                         securityOptions.ForPath(@"~\C$\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files", fs => fs.GrantReadWrite(settings.WebUserName));
                                     }

                                     securityOptions.ForCertificate(settings.CertificateThumbprint, c =>
                                     {
                                         c.GrantReadPrivateKey()
                                             .To(settings.WebUserName)
                                             .InStoreLocation(StoreLocation.LocalMachine)
                                             .InStoreName(StoreName.My);
                                     });

                                 });
                             });

                             
          DeploymentStepsFor(Host,
                             s =>
                             {
                                 var serviceName = "ServiceName.{{Environment}}";
                                 s.WinService(serviceName).Stop();

                                 s.CopyDirectory(@"..\_PublishedApplications\ServiceName").To(@"{{HostServicePath}}").DeleteDestinationBeforeDeploying();

                                 s.CopyFile(@"..\environment.files\{{Environment}}\{{Environment}}.servicename.exe.config").ToDirectory(@"{{HostServicePath}}").RenameTo(@"servicename.exe.config");

                                 s.Security(o =>
                                 {
                                     o.ForCertificate(settings.CertificateThumbprint, c =>
                                     {
                                         c.GrantReadPrivateKey()
                                             .To(settings.ServiceUserName)
                                             .InStoreLocation(StoreLocation.LocalMachine)
                                             .InStoreName(StoreName.My);
                                     });
                                     o.LocalPolicy(lp =>
                                     {
                                         lp.LogOnAsService(settings.ServiceUserName);
                                         lp.LogOnAsBatch(settings.ServiceUserName);
                                     });

                                     o.ForPath(settings.HostServicePath, fs => fs.GrantRead(settings.ServiceUserName));
                                     o.ForPath(Path.Combine(settings.HostServicePath,"logs"), fs => fs.GrantReadWrite(settings.ServiceUserName));
                                     o.ForPath(settings.ServiceWorkDirectory, fs => fs.GrantReadWrite(settings.ServiceUserName));
                                     o.ForPath(settings.ServiceTriggerWatchDirectory, fs => fs.GrantReadWrite(settings.ServiceUserName));
                                     o.ForPath(settings.SecureWorkDirectory, fs => 
                                          { 
                                              fs.GrantReadWrite(settings.ServiceUserName);
                                              fs.RemoveInheritance();
                                              fs.Clear().Preserve(settings.ServiceUserName)
                                                  .RemoveAdministratorsGroup()
                                                  .RemoveUsersGroup();
                                          });
                                 });
                                 s.WinService(serviceName).Delete();
                                 s.WinService(serviceName).Create().WithCredentials(settings.ServiceUserName, settings.ServiceUserPassword).WithDisplayName("servicename({{Environment}})").WithServicePath(@"{{HostServicePath}}\servicename.exe").
                                     WithStartMode(settings.ServiceStartMode)
                                     .AddDependency("MSMQ");

                                 if (settings.ServiceStartMode != ServiceStartMode.Disabled && settings.ServiceStartMode != ServiceStartMode.Manual)
                                 {
                                     s.WinService(serviceName).Start();
                                 }
                             });
      });
  }

    //order is important
    public static Role Db { get; set; }
    public static Role Web { get; set; }
    public static Role Host { get; set; }
}
}

You might immediately see how this really sets up an environment. The biggest ideas in DropkicK are that you can specify a complete setup from nothing to having a machine completely set up.

RoundhousE–Intelligent Database Migrations And Versioning

Rob Reynolds — Sun, 23 Oct 2011 15:21:00 GMT

“Because everyone wants to kick their database, but sometimes kicking your database is a good thing!”

Many would not argue that you should version your code, and few would argue against versioning your code in a way that can lead back to a specific point in source control history. However, most people don’t really think of doing the same thing with your database. That’s where RoundhousE (RH) comes in.

I have been working on RH for over two years now and people always wander what it is, why and what sets it apart from other migrators. We set out to make a smart tool for migrations that came somewhat close to Ruby’s ActiveRecord Migrations without going the code migrations route (yet). Hopefully this introduction will help you understand why it is different and whether it’s something that is in line with your needs.

What is RoundhousE?

RoundhousE (http://projectroundhouse.org) is a database migrator that uses plain old SQL Scripts to transition a database from one version to another. RoundhousE currently works with Oracle, SQL Server (2000/2005/2008/Express), Access, MySQL, and soon SQLite and PostgreSQL. It comes in the form of a tool, MSBuild, and an embeddable DLL. While someone is working on a GUI, there is no visual tool at the current time.

What sets RoundhousE apart from other migrators?

It subscribes to the idea of convention over configuration, which means you can pass the migrator very few configuration options to get it to work (rh.exe /d dbname), but pass as many options as necessary to meet your conventions. Say you don’t like the tables or folder names that RH uses, you can override those to whatever you want.

RH versions the database how you want it versioned. You can supply it with a DLL path for it to pull the file version from. You can give it an XML file and XPath, or you can use the highest script number in the up folder. You can also just use a sequence based (non-global) form of passive versioning. https://github.com/chucknorris/roundhouse/wiki/Versioning

RH believes in low maintenance and keeping good clean history in your source control. This means that you don’t lump everything into one folder, you put your anytime scripts (views/functions/stored procedures/etc) into their own folders and track history as you go. RH is smart enough to only run these if they are new/different from the current existing scripts in the database.

RH has three modes of operation. Normal, DropCreate, and Restore. Notice none of those are Create like you may see in other migrators. If the intent in the end is to have a database ready to go, why would you want to have to make a step to specify that you want to create the database? RH is smart enough to realize that the database doesn’t exist and it creates it (unless you pass a switch explicitly telling it not to). Normal is just the migration as it is. DropCreate is used during development when you want to continually change the same scripts prior to production. Restore is used when you switch to maintenance mode and want to change the same maintenance script. https://github.com/chucknorris/roundhouse/wiki/RoundhousEModes

RH is environment aware, which means you can have environment specific scripts. If you have scripts or permissions scripts that are different for each environment you can give them a special name. https://github.com/chucknorris/roundhouse/wiki/EnvironmentScripts

RH is an easy to start using on legacy databases. You just take your old DDL/DML scripts and move them into a special folder that RH will only evaluate/run when it is creating a database (say on a new developers machine). You can arrange existing scripts into RH default folders or point RH to the existing folder types. RH splits scripts with the GO batch terminator in them.

RH speeds up your development process. You can use RH with NHibernate to refresh your database without leaving Visual Studio! Entity Framework and FluentMigrator are planned for this feature as well. https://github.com/chucknorris/roundhouse/wiki/Roundhouserefreshdatabasefnh

RH runs on just the .NET framework. This means you don’t need SMO installed like some other migrators require.

While there are probably other features I haven’t mentioned, keep in mind that RH is not a code migrator (yet). If you are looking for a code migrator, there are quite a few good tools out there, including FluentMigrator and Mig#. Entity Framework Code Migrations is really starting to shape up as well (Seriously! Although EF only works for SQL Server).

How do I get RoundhousE?

There are several avenues to get RH. You can use NuGet, Chocolatey, Gems, plain old downloads (still considered official releases), or source (both in git and svn). https://github.com/chucknorris/roundhouse/wiki/Getroundhouse

Let’s Get Chocolatey! Kind of like apt-get for Windows

Rob Reynolds — Fri, 07 Oct 2011 12:32:28 GMT

“If only there was some way to quickly and silently install applications and tools on my windows machine.”

Chocolatey is kind of like an apt-get, but for Windows. It is a machine level package manager that is built on top of NuGet command line and the NuGet infrastructure. Jason Jarrett recently described it as the free/OSS windows app store. What that means for you is that you can install and update software (applications and tools) on your machine with a few keystrokes and chocolatey does the rest!

Just how easy is it to install an application? From the command line, PowerShell, or Package Manager Console in visual studio you can type something like:

cinst windirstat

and watch it download and silently install WinDirStat on your machine.

A picture is worth a thousand words in this case:

If you want to try a tool (something that doesn’t actually install on your machine), try baretail, nodejs, or ravendb.

Creating Packages is also very simple: https://github.com/chocolatey/chocolatey/wiki/CreatePackages

Below is all that is required to install WinDirStat on your machine.

Install-ChocolateyPackage 'windirstat' 'exe' '/S' 'http://windirstat.info/wds_current_setup.exe'

Include chocolatey in your development environment setup! https://github.com/chocolatey/chocolatey/wiki/DevelopmentEnvironmentSetup Check out a living example - https://github.com/davidalpert/nuserve#readme

FAQ

What can I do with chocolatey? Since it uses PowerShell, you can do nearly anything you can do with .NET. Install applications, download tools and put them on the path, set up contributors machines for hacking on your code, install powershell commands, etc. Your imagination is the limit!

What’s your best example of the power of chocolatey? One line Ruby DevKit install. Seriously. http://groups.google.com/group/rubyinstaller/browse_thread/thread/8245c53f990d1ea6

I’m convinced! How do I install chocolatey? We try to make that simple as well. Open powershell, make sure execution policy is unrestricted (Set-ExecutionPolicy Unrestricted), and paste

iex ((new-object net.webclient).DownloadString("http://bit.ly/psChocInstall"))

I have included tools (executables) in my nuget.org packages, like Statlight and Fubu. Can I use chocolatey to “install” them? Yes, just call install like normal, it will check chocolatey.org first and then nuget.org. If it finds an executable in the package, it will automatically put it on the path.

How is chocolatey different from other windows machine package managers? It has PowerShell instructions for how to download native installers from the distribution source and install applications on your machine. It uses PowerShell so you can give it any instruction you want for install and configuration. It automatically makes batch command file links for executables you have included in your package or have downloaded to the package directory with the PowerShell script.

Is chocolatey awesome? I’m biased, but YES!

Is chocolatey version 1? Not yet, we have a few things going into the roadmap and enhancements being logged: https://github.com/chocolatey/chocolatey/issues

I’m not convinced, where do I find more information? I’ve listed quite a few resources below. I am likely missing some.

References

http://chocolatey.org/

https://github.com/chocolatey/chocolatey/wiki

http://groups.google.com/group/chocolatey

http://twitter.com/chocolateynuget

Videos

Chocolatey In Action (11 apps/tools in less than 7 minutes!): http://www.youtube.com/watch?v=N-hWOUL8roU

Create a Chocolatey Package: http://www.youtube.com/watch?v=Wt_unjS_SUo

Blog Posts

This dates all the way back to March 2011. Chocolatey has been actively worked on for awhile…

http://nuget.codeplex.com/discussions/251435

http://nuget.codeplex.com/discussions/257341

http://chrisortman.wordpress.com/2011/04/01/getting-started-with-chocolatey/

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/chocolatey-apt-get-for-windows

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/getting-chocolatey-to-work-when

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/chocolatey-gui

http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/making-a-chocolatey-package

http://www.counity.at/blog/archives/253

http://www.xavierdecoster.com/post/2011/09/30/An-overview-of-the-NuGet-ecosystem.aspx

http://blog.codiceplastico.com/melkio/index.php/2011/10/06/chocolatey-un-package-manager-per-windows/

http://elegantcode.com/2011/10/05/chocolatey-the-free-and-open-source-windows-app-store

Extend NuGet Command Line

Rob Reynolds — Fri, 15 Jul 2011 08:00:00 GMT

Yesterday I started a discussion about adding a new command to nuget.exe. It ended in creating an extension to the command line that behaves in the same way without having to dive into the nuget code base or add more complexity to it.

I haven’t seen any blog posts or documentation surrounding this new concept (new in nuget 1.4) of extending the command line except for Matt Hamilton’s posts on using NuGet for plug-ins and NuGet with MEF (which are not quite this concept).

Here is my experience. I found looking at the commands in nuget.exe (NuGet.Commands) to make it easy to create my own command and extend NuGet. Some of this information may not be exactly what you should do, but it worked for me.

The Code

Create a new Visual Studio Solution and add a Class Library (full .NET 4.0 framework).
Add A NuGet Reference to Nuget.CommandLine.
Now manually add a reference to nuget.exe. Yes, you can add references to .NET executables.
Adding a reference to nuget.exe gives you access to Command and the CommandAttribute. These are what I see as necessary to extending NuGet.
Add a reference to System.ComponentModel.Composition (MEF).
Now you provide a class and resource file per command.

The resource file contains the command descriptions:

The class is attributed with CommandAttribute and inherits from Command.

[Command(typeof (CopyResources), "copy", "Description", MinArgs = 1, MaxArgs = 5, UsageSummaryResourceName = "UsageSummary",UsageDescriptionResourceName = "UsageDescription")]
public class Copy : Command {}

The Command Attribute asks for a few things:

typeof (CopyResources) – ResourceClass - What is the resx file that the command will draw its help information from?
“copy” – CommandName - what is the name of the command?
“Description” – Description - resource name in the resource file that gives the description on the command line.
MinArgs=1 – Minimum Arguments - what are the minimum number of arguments that can be passed to this command and satisfy its needs?
MaxArgs = 5 – Maximum Arguments - what are the maximum number of arguments that can be passed to this command?
UsageSummaryResourceName = “UsageSummary” – UsageSummary - a very short amount of information that explains the usage of the command.
UsageDescription = “Usage Description” – UsageDescription - more detailed information about how to use the command.

Here is what the command looks like when run with help. Notice where from the CopyResources.resx these items match up to the screen.

Now that we have the command attribute finished, let’s work on the command itself.

private readonly IPackageRepositoryFactory _repositoryFactory;
private readonly IPackageSourceProvider _sourceProvider;

[ImportingConstructor]
public Copy(IPackageRepositoryFactory repositoryFactory, IPackageSourceProvider sourceProvider)
{
    _repositoryFactory = repositoryFactory;
    _sourceProvider = sourceProvider;
}

[Option(typeof (CopyResources), "SourceDescription", AltName = "src")]
public string Source { get; set; }

[Option(typeof (CopyResources), "DestinationDescription", AltName = "dest")]
public string Destination { get; set; }

[Option(typeof (CopyResources), "VersionDescription")]
public string Version { get; set; }

[Option(typeof (CopyResources), "ApiKeyDescription")]
public string ApiKey { get; set; }

public override void ExecuteCommand()
{
    string packageId = base.Arguments[0];

    Console.WriteLine("Copying {0} from {1} to {2}.", string.IsNullOrEmpty(Version) ? packageId : packageId + " " + Version,
                      string.IsNullOrEmpty(Source) ? "any source" : Source, Destination);

    //do work son
 
}

Important things to note:

[ImportingConstructor] is the constructor that will be called. Notice I am having it get passed an IPackageRepositoryFactory and an IPackageSourceProvider. Most of my work is already done for me setting these up in the command line application.
Each command line option has [Option(typeof (CopyResources), "DestinationDescription", AltName = "dest")] .
Notice again with the options we specify the Resource File with an Option Description (“DestinationDescription”) and an optional short parameter for the Option (AltName). Notice how that translates into options on the help command.
I am overriding ExecuteCommand and pulling the packageId as the first item from base.Arguments.

From here I can do all the work necessary for my custom command.

Get NuGet to Recognize It

Nuget looks for custom commands in %LocalAppData%\NuGet\Commands. Drop your DLL in there and then call nuget. See if it registers your command. This will allow you to continue to tweak your package prior to releasing it in the wild.

Use AddExtension to Add New Commands

NuGet Extend (AddConsoleExtension) makes installing new commands to the console from NuGet packages super easy. You install it by typing the following:

NuGet.exe Install /ExcludeVersion /OutputDir %LocalAppData%\NuGet\Commands AddConsoleExtension

From then on, adding a new extension is as easy as

nuget.exe addExtension packageName

Distribute Your Extension as a NuGet Package And Enjoy Your New Custom Command

When I created my package, I noted in the nuspec description that Nuget Extend should be installed first. I also added the tag ConsoleExtension since that is what NuGet Extend used. All I package up is the DLL. The nuspec has ZERO dependencies specified (I do not include that I have a dependency on NuGet.CommandLine). I don’t need to include the nuget dependency since that will be resolved when the extension is run with nuget.exe.

Now that you have your custom command, enjoy life a little easier. And tell others about it.

NuGet Copy Extension is the extension I wrote that pulls packages from one source and pushes them to another. If you are a company that wants to house packages in a company feed and perhaps shut off the official feed for the rest of your developers, then this command may come in very handy.

Have Fun!

Iowa Code Camp Presentations

Rob Reynolds — Fri, 06 May 2011 05:04:21 GMT

Last weekend I went up to Iowa Code Camp in Cedar Rapids and had the opportunity to do two presentations, one on NuGet and one known as the Automation Tools Roundup. ICC is one of my favorite conferences every year. It is twice a year and I try to make it to at least one of them. The people that attend this conference really make it worth the money you spend in travel expenses. Definitely recommended.

Automation Tools Roundup

This is my favorite session to give because it requires crowd participation and it is never the same presentation twice. We just start going through automation tools of any sort that can help people be more productive through their use. The crowd picks which ones we talk about (for the most part). If there is time at the end we find ourselves trying to learn new tools.

We talked about several tools and as part of the session people from the audience are invited to come up and talk about a tool they like. Keith Dahlby came up and talked about Posh-Git which has an awesome interface for showing me my git status right on the prompt.

Other tools covered:

Chocolatey – I am going to talk about this tool soon.
Launchy
Console2
ChuckNorrisFramework: UppercuT & WarmuP were demoed, RoundhousE & DropkicK were mentioned
StExBar & grepWin
Notepad++
PSake was mentioned
SysInternals was mentioned, ZoomIt was shown

I believe we talked about a few more tools. If you were there and you remember, please hit the comments! Because this presentation is so dynamic, there are no slides.

FREE as in BEER!! Manage Your Packages w/NuGet

I enjoy showing people what is possible out there, even with some of the things that are not perfect. NuGet has a few kinks, but the community is helping and the team is committed to continually making the product better. This presentation is dedicated to showing you how to get started to building your own packages to hosting your own feed. We look at the GUI, the powershell console, the command line and the package explorer. The last 10 minutes of the presentation are dedicated to a new tool that can help make you hyper productive! This presentation is a lot of fun and seeing people really understand what NuGet can do for them is awesome!

Here are the slides: http://dl.dropbox.com/u/9391884/NuGet.ppsx

MVP Renewal and News

Rob Reynolds — Thu, 14 Apr 2011 05:22:03 GMT

It appears that my work in the community and the nominations received from others has secured my status as an MVP for a second year.

Thank you all for the award and thank you everyone (including Microsoft) for valuing my contributions to the community.

I noticed last year I did quite a bit of travelling and talks. I’m going to need to work hard to keep that up this year. I’m also hoping to gear up for the v1 release of RoundhousE and DropkicK as well as something new I’ve been working on known as chocolatey (more on this in a future post – stay tuned!). This year as well hope to get out to some of my favorite conferences (like Iowa Code Camp), start v2 of UppercuT (that Dru and I have been talking about almost as long as UC has been around), and get some of these other tools to work on Linux (UC already does).

I’m pretty excited about this year and recently changed jobs back in February for those who may not have heard. Now instead of working for a bank that has no money inside and the doors are always locked, I’ll be playing with Crop Insurance.

Do me a favor and nominate Dru Sellers for MVP (Visual C#). His contributions to where many people are as developers/individuals (including me) would not have been possible without his influence and mentorship. His investment in others is huge and that is a defining factor of the MVP program.

Published Applications AKA _PublishedApplications

Rob Reynolds — Wed, 23 Mar 2011 02:23:12 GMT

Less maintenance. Less work to package during your automated builds. Too easy.

Remember Our Old Friend _PublishedWebsites?

You’ve probably seen the _PublishedWebsites folder when building websites in automated builds. If not you can stop paying attention now.

Still with me? Great! So you know how it packages up everything nicely with content files going where they should with nearly ZERO cost to your build scripts. All you need to do is override the output directory (OutDir) and you get this feature. This behavior is arguably one of the best things that web projects do during automated builds.

So how many of you, like me, just accepted the fact that this was just for web, and not other applications, and went on maintaining your build scripts to package up your other application types? Yeah, me too. Painful…and we looked at complicated ways of solving this problem. There has to be a better way.

Introducing _PublishedApplications

Recently David Keaveny came up with an idea to take the Microsoft.Web.targets file (which produces the _PublishedWebsites folder – it is imported by the csproj/vbproj file), change up a couple of variables and rename it to the Microsoft.Application.targets file. When I saw this I thought this was an awesome idea! How come I didn’t think of that? Why didn’t anyone else see the simple solution?

The concept is simple – You add the .targets file to your application. Then you edit the csproj/vbproj file by hand to add in the import for the .targets file.

And you get a nice folder with your application bits nicely packaged for you.

Note: The _PublishedApplications folder ONLY shows up when you override the output directory during an automated build or command line access to building a solution. The rest of the time your builds go to their normal folders (i.e. bin\Debug).

PublishedApplications Is On NuGet

I loved this idea so much I did the work to figure out how to automate the imports part of the idea so it was a simple command to use Microsoft.Application.targets. And this is on NuGet: http://nuget.org/list/packages/publishedapplications

Install-Package PublishedApplications

Want A Demonstration?

Why talk when we can just look at a short video that demonstrates this idea?

Install-Package PublishedApplications

Special thanks to David Keaveny for this great idea!

From Zero To Deployed Contest - Winner Announced PLUS Extension To Most Creative

Rob Reynolds — Mon, 21 Mar 2011 05:01:40 GMT

Recently we had a contest to see who could beat my time to get from no code to deployed. Thanks to everyone that participated and everyone that thought about participating in the contest.

Most Creative From Zero To Deployed Contest Extended!

Unfortunately there were not enough entries to award the most creative video for ZtD. So what we are doing is extending the most creative until May 15, 2011 @ 11:59 PM CST. This gives you almost two months to get your videos in! If you entered before, you are allowed to re-enter for the most creative (even if you won the first contest).There is no minimum number of entries this time around either. Refresh yourself of the rules/prizes from the last post and get coding!

And The Winner Is…

I want to thank those that participated. It takes a lot to code against the clock, and even more to capture it on video and put it up for the world to see. Those two factors alone helped me realize I wouldn’t get a lot of entries and I’m excited that at least two people jumped in with submissions! Cool points to all participants.

As long as the rules were followed, the person with the best time would win. And that person would win $2348 worth of prizes! To recap the prizes:

$50 Gift Card (provided by me)
$100 service credit for AppHarbor (provided by AppHarbor)
Full personal license of ReSharper (provided by Jet Brains)
Telerik Ultimate Collection for .NET (provided by Telerik)

And the winner is James Pogran with a time of 5:50! Congratulations man! Be sure to give him a shout out on twitter!

From Zero To Deployed Contest - Prizes Announced

Rob Reynolds — Wed, 23 Feb 2011 00:33:59 GMT

Do you have what it takes to meet the challenge? We’ll make it worth it.

You may have noticed at the end of my last post I threw down the community challenge to get from zero to deployed faster than me.

The Challenge

My time was 13:48 to be from zero to deployed. Beat my time and show it in a video response. The person with the best time by March 15th @ 11:59PM CST will receive a prize.

Here are the links to the videos:

The Rules

Let’s revisit those ground rules before I tell you what the prizes will be:

Ground rules:

.NET Application with a valid database connection
Start from Zero
Deployed with AppHarbor or an alternative
A timer displayed in the video that runs during the entire process
Video response published on YouTube or acceptable alternative
Video(s) must be published by March 15th at 11:59PM CST.
Either post the link here as a comment or on YouTube as a response (also by 11:59PM CST March 15th)

The Prizes

The prize package for the best time is:

$50 Gift Card or equivalent – Provided by yours truly.
AppHarbor $100 service credit – AppHarbor will provide a $100 credit for their services once they launch payments. Thank you to the folks at AppHarbor!
ReSharper - Jetbrains will provide a FULL license of ReSharper Personal. This license is a $199 value. Thank you to the folks at Jetbrains!
Telerik Ultimate Collection for .NET – Telerik will provide a license to pretty much every .NET tool they offer. This license is a $1999 value. A big thank you to the folks at Telerik!!
This is a total value of $2348!!!

The prize package for the person that has the most creative video(s) with a time better than mine (if there are at least 5 responses):

$20 Gift card or equivalent – Provided by this guy.
AppHarbor $50 service credit – same deal as above. Thank you AppHarbor!
Twilio T-Shirt - Twilio has donated a shirt and will ship your size to you (this may be subject to US residents only). This is a $25 value. Thank you to the folks at Twilio!

AppHarbor - Azure Done Right AKA Heroku for .NET

Rob Reynolds — Wed, 16 Feb 2011 12:49:23 GMT

Easy and Instant deployments and instant scale for .NET?

Awhile back a few of us were looking at Ruby Gems as the answer to package management for .NET. The gems platform supported the concept of DLLs as packages although some changes would have needed to happen to have long term use for the entire community. From that we formed a partnership with some folks at Microsoft to make v2 into something that would meet wider adoption across the community, which people now call NuGet. So now we have the concept of package management. What comes next?

Heroku

Instant deployments and instant scaling. Stupid simple API. This is Heroku. It doesn’t sound like much, but when you think of how fast you can go from an idea to having someone else tinker with it, you can start to see its power. In literally seconds you can be looking at your rails application deployed and online. Then when you are ready to scale, you can do that. This is power. Some may call this “cloud-computing” or PaaS (Platform as a Service).

I first ran into Heroku back in July when I met Nick of RubyGems.org. At the time there was no alternative in the .NET-o-sphere. I don’t count Windows Azure, mostly because it is not simple and I don’t believe there is a free version. Heroku itself would not lend itself well to .NET due to the nature of platforms and each language’s specific needs (solution stack). So I tucked the idea in the back of my head and moved on.

AppHarbor Enters The Scene

I’m not sure when I first heard about AppHarbor as a possible .NET version of Heroku. It may have been in November, but I didn’t actually try it until January. I was instantly hooked. AppHarbor is awesome! It still has a ways to go to be considered Heroku for .NET, but it already has a growing community. I created a video series (at the bottom of this post) that really highlights how fast you can get a product onto the web and really shows the power and simplicity of AppHarbor.

Deploying is as simple as a git/hg push to appharbor. From there they build your code, run any unit tests you have and deploy it if everything succeeds. The screen on the right shows a simple and elegant UI to getting things done.

The folks at AppHarbor graciously gave me a limited number of invites to hand out. If you are itching to try AppHarbor then navigate to: https://appharbor.com/account/new?inviteCode=ferventcoder

After playing with it, send feedback if you want more features. Go vote up two features I want that will make it more like Heroku.

Disclaimer: I am in no way affiliated with AppHarbor and have not received any funds or favors from anyone at AppHarbor. I just think it is awesome and I want others to know about it.

From Zero To Deployed in 15 Minutes (Or Less)

Now I have a challenge for you. I created a video series showing how fast I could go from nothing to a deployed application. It could have been from Zero to Deployed in Less than 5 minutes, but I wanted to show you the tools a little more and give you an opportunity to beat my time.

And that’s the challenge. Beat my time and show it in a video response. The video series is below (at least one of the videos has to be watched on YouTube). The person with the best time by March 15th @ 11:59PM CST will receive a prize.

Ground rules:

.NET Application with a valid database connection
Start from Zero
Deployed with AppHarbor or an alternative
A timer displayed in the video that runs during the entire process
Video response published on YouTube or acceptable alternative
Video(s) must be published by March 15th at 11:59PM CST.
Either post the link here as a comment or on YouTube as a response (also by 11:59PM CST March 15th)

From Zero To Deployed In 15 Minutes (Or Less) Part 1

From Zero To Deployed In 15 Minutes (Or Less) Part 2

From Zero To Deployed In 15 Minutes (Or Less) Part 3

UppercuT v1.2–NuGet Support

Rob Reynolds — Mon, 24 Jan 2011 02:18:57 GMT

For those that have not yet heard, NuGet went v1 recently along with a whole slew of tools from the Microsoft folks. I’ve been lucky to be a part of the NuGet project and see it take shape over the past few months with community input and contributions. Even though v1.0 was released, we are already moving forward with getting ideas and prioritizing features for the next version.

To follow the announcement, UppercuT (UC) v1.2 now includes support for NuGet out of the box. Plus, it will handle versioning the nuspec file for you, a highly requested feature for those that worked with other package managers.

UppercuT + NuGet == Can Packaging Get Any Easier?

It can. UC exists to take the pains out of builds. To go from zero to your first NuGet package with the goodness of UC, just read on and follow the directions. If you are already creating nuget packages, UC can help update the version in the nuspec for you automatically. Read on…

Upgrading?

1. For those upgrading, you bring over the entire contents of the build directory like before. Please see the downloads (or the ReadMe ReleaseNotes section) for any items you need to change between your previous version and the latest version of UC you are downloading.

2. You will want to add the following to your UppercuT.config file:

<property name="app.nuget" value="..${path.separator}${folder.references}${path.separator}NuGet${path.separator}NuGet.exe" overwrite="false" />

2. Include the NuGet folder in your lib directory from the UC distribution (or get the latest NuGet.exe and drop it in a NuGet folder under lib):

3. Add the nuget directory at your top level (next to the build.bat file) from the UC distribution:

New to Uppercut?

1. There is a nice write up on how to get UC set up on your project in less than 5 minutes (or you can try the gems approach)! It really shows how little is needed to get a fully conventional build with the ability to upgrade in seconds instead of hours for your builds.

Getting Some Nuget-ty Goodness To Your Builds

1. Head into the top level nuget folder. Rename the __NAME__.nuspec file to the name of your nugget (most likely your project name if there are no other packages named the same). Here we are working with SidePOP, so I named it sidepop.nuspec.

2. Let’s open that file and take a look.

<?xml version="1.0"?>
<package xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <metadata>
    <id>__REPLACE__</id>
    <version>DO_NOT_EDIT</version>
    <authors>__REPLACE__</authors>
    <owners>__REPLACE__</owners>
    <summary>__REPLACE__</summary>
    <description>__REPLACE__</description>
    <!--<projectUrl>__REPLACE__</projectUrl>
    <licenseUrl>__REPLACE__</licenseUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <tags>space delimited</tags>
    <iconUrl>32x32.png</iconUrl>
    <dependencies>
      <dependency id="something" version="1.0.0.0" />
    </dependencies>-->
  </metadata>
</package>

NOTE: Notice the metadata attribute doesn’t have the xmlns in it (xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"). This needs to be removed for xpath to be able to replace the version. If you are bringing an existing nuspec in, you will want to remove that.

3. Look how most things say __REPLACE__. The version attribute does not. Do not edit version (if you do, it will just be replaced during the build).

4. Let’s set up the nuspec for SidePOP. SidePOP has a dependency on log4net version 1.2.10.

<?xml version="1.0"?>
<package xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <metadata>
    <id>sidepop</id>
    <version>DO_NOT_EDIT</version>
    <authors>Rob Reynolds, Tim Hibbard</authors>
    <owners>Rob Reynolds</owners>
    <summary>SidePOP gives your app the ability to receive email</summary>
    <description>SidePOP allows your application the ability to receive email</description>
    <projectUrl>http://sidepop.googlecode.com</projectUrl>
    <licenseUrl>http://www.apache.org/licenses/LICENSE-2.0</licenseUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <tags>email</tags>
    <!--<iconUrl>32x32.png</iconUrl>-->
    <dependencies>
      <dependency id="log4net" version="1.2.10" />
    </dependencies>
  </metadata>
</package>

5. We also have content transformation for the config file, so we’ll include that in the nuget folder.

6. In that we will create our transforms for the web.config and app.config.

7. Now we go back up to our top level folder and run build.bat.

8. If we head down to our code_drop/nuget folder, you can see we have a nupkg with the right version on it!

9. Now all we have to do is look to be sure we have everything we want and we can upload. In my case I need to exclude the log4net file I have, so I need to delete that one from the directory during the build process. How do I get in? UC Extension Points of course!

10. If I drop into the build folder and open a command line I can type: customize nugetPrepare.step post

11. This will create an extension point file for me in build.custom.

12. Open that file and let’s remove the log4net file from the nuget drop directory prior to the nuget build. This is how I set up that file:

<?xml version="1.0" encoding="utf-8"?>
<project name="CUSTOM POST NUGETPREPARE" default="go">
  <!-- Project UppercuT - http://projectuppercut.org -->
  <property name="build.config.settings" value="__NONE__" overwrite="false" />
  <include buildfile="${build.config.settings}" if="${file::exists(build.config.settings)}" />
  <property name="path.separator" value="${string::trim(path::combine(' ', ' '))}" />
  <property name="dirs.current" value="${directory::get-parent-directory(project::get-buildfile-path())}" />
  <property name="path.to.toplevel" value=".." />
  <property name="folder.code_drop" value="code_drop" overwrite="false" />
  <property name="dirs.drop" value="${dirs.current}${path.separator}${path.to.toplevel}${path.separator}${folder.code_drop}" overwrite="false" />
  <property name="dirs.drop" value="${path::get-full-path(dirs.drop)}" />
  <property name="folder.nuget" value="nuget" overwrite="false" />
  <property name="dirs.drop.nuget" value="${dirs.drop}${path.separator}${folder.nuget}" overwrite="false" />
  
  <target name="go">
    <echo message="Removing log4net from '${dirs.drop.nuget}\lib'" />
    <delete>
      <fileset basedir="${dirs.drop.nuget}\lib" >
        <include name="log4net.*" />
      </fileset>
    </delete>
  </target>
  
</project>

13. Now looky here, log4net is no longer in my package.

14. Now I am ready to test my package before I push it out by putting it in a local feed and grabbing it.

15. All good. Now I can upload and put my package on the official feed!

NOTE: SidePOP is in Alpha. If you want to use it to check email, it works, but be prepared for possible errors.

Conclusion – UppercuT and NuGet – A Good Team!

You can see how fast we went from ZERO NuGet to up on the http://nuget.org site! In 4 steps I was already building a NuGet package, and in less than 15 steps it was production ready! What are you waiting for? Go UppercuT your code now!

If you have any UC related questions when getting it all NuGet-ty, feel free to contact the list: http://groups.google.com/group/chucknorrisframework

With this knowledge, you shall build.

UppercuT v1.0 and 1.1–Linux (Mono), Multi-targeting, SemVer, Nitriq and Obfuscation, oh my!

Rob Reynolds — Thu, 13 Jan 2011 19:04:54 GMT

Recently UppercuT (UC) quietly released version 1 (in August). I’m pretty happy with where we are, although I think it’s a few months later than I originally planned. I’m glad I held it back, it gave me some more time to think about some things a little more and also the opportunity to receive a patch for running builds with UC on Linux. We also released v1.1 very recently (December).

UppercuT v1

Builds On Linux

Perhaps the most significant changes to UC going v1 is that it now supports builds on Linux using Mono! This is thanks mostly to Svein Ackenhausen for the patches and working with me on getting it all working while not breaking the windows builds! This means you can use mono on Windows or Linux.

Notice the shell files to execute with Linux that come as part of UC now.

Multi-Targeting

Perhaps one of the hardest things to do that requires an automated build is multi-targeting. At v1 this is early, and possibly prone to some issues, but available.

We believe in making everything stupid simple, so it’s as simple as adding a comma to the microsoft.framework property. i.e. “net-3.5, net-4.0” to suddenly produce both framework builds.

When you build, this is what you get (if you meet each framework’s requirements):

At this time you have to let UC override the build location (as it does by default) or this will not work.

Semantic Versioning

By now many of you have been using UppercuT for awhile and have watched how we have done versioning. Many of you who use git already know we put the revision hash in the informational/product version as the last octet.

At v1, UppercuT has adopted the semantic versioning scheme. What does that mean?

This is a short read, but a good one: http://SemVer.org

SemVer (Semantic Versioning) is really using versioning what it was meant for. You have three octets. Major.Minor.Patch as in 1.1.0. UC will use three different versioning concepts, one for the assembly version, one for the file version, and one for the product version.

All versions - The first three octects of the version are owned by SemVer.

Major.Minor.Patch
i.e.: 1.1.0

Assembly Version - The assembly version would much closer follow SemVer. Last digit is always 0.

Major.Minor.Patch.0
i.e: 1.1.0.0

File Version - The file version occupies the build number as the last digit.

Major.Minor.Patch.Build
i.e.: 1.1.0.2650

Product/Informational Version - The last octect of your product/informational version is the source control revision/hash.

Major.Minor.Patch.RevisionOrHash
i.e. (TFS/SVN): 1.1.0.235
i.e. (Git/HG): 1.1.0.a45ace4346adef0

SemVer is not on by default, the passive versioning scheme is still in effect. Notice that version.use_semanticversioning has been added to the UppercuT.config file (and version.patch in support of the third octet):

Gems Support

Gems support was added at v1. This will probably be deprecated as some point once there is an announced sunset for Nu v1. Application gems may keep it around since there is no alternative for that yet though (CoApp would be a possible replacement).

Nitriq Support

Nitriq is a code analysis tool like NDepend. It’s built by Mr. Jon von Gillern. It uses LINQ query language, so you can use a familiar idiom when analyzing your code base. It’s a pretty awesome tool that has a free version for those looking to do code analysis!

To use Nitriq with UC, you are going to need the console edition. To take advantage of Nitriq, you just need to update the location of Nitriq in the config:

Then add the nitriq project files at the root of your source.

Please refer to the Nitriq documentation on how these are created.

UppercuT v1.1

Obfuscation

One thing I started looking into was an easy way to obfuscate my code. I came across EazFuscator, which is both free and awesome. Plus the GUI for it is super simple to use.

How do you make obfuscation even easier? Make it a convention and a configurable property in the UC config file!

And the code gets obfuscated!

Closing

Definitely get out and look at the new release. It contains lots of chocolaty (sp?) goodness. And remember, the upgrade path is almost as simple as drag and drop!

The Evolution of Package Management for .NET

Rob Reynolds — Wed, 06 Oct 2010 17:54:00 GMT

The thing to realize is that the destination is never the most important part of the journey. It’s the journey itself.

When you start a journey, you are never fully sure where it is going to end up. We started the journey down package management for .NET three times with Nu[bular] (we in this context means the nu team, not me in particular, I was only involved in the last reboot) before we decided to try an existing infrastructure with Ruby Gems. I have always said that I would use the best tool out there, even if it is not one that I’ve been involved in building.

Personally I’ve always felt that competition is important to drive out the best features and make all products involved better. The community benefits with competition. If you’ve spent any time with me or listened to me on twitter, you can see that I support the idea of Noodle (Bundler/gems for .NET), Horn and OpenWrap. Each of them solves a similar problem in a different way. Each of them has great things about them. Having choices is good. Not everyone likes things the same way. I like my eggs over easy. I’m not going to force the way I like my eggs when I cook for you, but I’m going to cook them that way for me.

It’s important to realize that the destination is never the most important part of the journey. It’s the journey itself. Two months ago we decided to make Nu with Ruby and use the gems infrastructure. It was like the stars aligned – Ruby Midwest Conference was next door in KC, so we got to spend some time with Nick Quaranto, one of the guys behind GemCutter, also known as RubyGems.org. At that time we discussed at length what our plans were and got a blessing to park gems on their server while running the Nu experiment. Many of our friends and colleagues had also been pining for some sort of package management so everyone was quick to jump onto a proven infrastructure that is super easy to use. When we introduced it, it’s amazing how many people brought the awesome to Nu/Gems.

Nubular

Nu Is Awesome! Being part of the last two reboots I have learned quite a bit about package management and that knowledge and the knowledge that everyone else has learned can be applied to any package management tool. There have been so many great ideas from those in the community and lots of great questions from everyone. Those questions and answers apply to other package management tools.

Having something that builds on an existing infrastructure helped us bootstrap so fast that we were allowed to start working on the interesting features immediately. This has been helpful in getting us to the .NET intricacies and finding ways to solve them. I’ve been blessed to be part of this project.

Microsoft Introduces Package Management – NuPack

From the front page of CodePlex “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.” NuPack is a collaborative project in the Outercurve Foundation. It is an Open Source Project, and truly the first of it’s type, with Microsoft Employees working full time on it and open source developers contributing at the same time. The core team is not just Microsoft and that means the tool will have the influence of the community at large. This means that like the Orchard Project, you or I can contribute. Unlike the Orchard Project, you and I have an opportunity to contribute core features (given that the right conditions are met).

This is NOT the same Microsoft

No one had any idea that Nu was going to be so explosively popular when it came out two months ago. After all, we started it as an experiment to see if we could even do it. Years ago, Microsoft would have ignored what was happening in the community and just introduced what they were working on without seeming to try to really understand the needs of the community. They have been criticized again and again for appearing to follow a “not invented here” model. When they saw how successful our last reboot of Nubular was, they pulled us in to show us what they had been working on for four months prior to our last reboot and started asking for input on how they could ensure it meets the needs of the community.

But then Microsoft did something different. They made the project OSS and pulled in a few open source developers (including the Nu team) to both give feedback and contribute to the same codebase the full time MS employees are working with.

Make no mistake on the name. Microsoft renamed their tool from the codename NPack to NuPack to signify a merging of the community and what they were working on. Microsoft reached out to members of the community that have been involved with package management for feedback and support, including some that may be up in arms about Microsoft entering the arena.

Why is This Good For the Community?

Listen up Mr/Ms Open Source Provider, this is important for you.

Now let me take off my Nu/NuPack hat(s) for a minute and don my OSS (Open Source Software) provider hat. Let’s say you or I have a tool that we think is awesome and we want to get it into the hands of the community at large. In the .NET community, there is a largely untapped set of people that program in .NET that use Microsoft tools only. Most of them program at work using MS tools and go home and never look at Open Source alternatives (or even things OSS that have no Microsoft equivalent).

Most of this largely untapped audience only sees what Microsoft is doing and thus has never heard of your OSS tools. It’s like the iPhone4 vs HTC Evo video with the “I don’t care.” segment where one person is blind to better features of an alternative product.

Go ahead and watch, I’ll wait. I suggest headphones at work. And it’s funny. Really funny. So is the opposite take on HTC Evo vs. iPhone4.

So, back to the .NET community, you have these people that are blind to this whole community of open source tools for some reason or another. Package management itself is geared toward free/OSS tools and libraries, and having Microsoft behind it will start to open the eyes of this largely untapped community.

This means that you and I, working on these free/OSS tools that are great have more of an opportunity to fall into the hands of the full .NET community. That means that a larger user base could happen. That means more feedback and better tools as a result. That means… …and this is me REALLY dreaming at the moment, Alt.NET could become the mainstream .NET.

What is the Future of Nu?

If you’re still with me, the big pink elephant is in the room and I have not yet addressed it.

So, NuPack is out, what is the future of Nu? What a great question! Nu will co-exist with NuPack for awhile. When NuPack reaches a certain point, it’s ultimately going to be Nu version 2. I personally will continue to be involved with both projects until I see that NuPack does bring at least the same level of awesome as Nu like it promises it will. I don’t know what the date of the awesome is, but I can tell you that we will all realize when it is.

My support lies with the community and when the community is ready to shift, it will make sense to sunset Nubular. But it’s open source, so others could pick it up and take it in whole new directions. :D

Thank You

Thanks to everyone for the support! You have proven that the .NET-o-sphere needs package management and you have been willing to step up and give your time and efforts to help bootstrap the community. I am blessed to have been part of this thus far and am excited to see where the journey goes next.

On a side note, the herding code podcast was done a few hours after Microsoft first showed us NuPack and started asking for feedback. That was August 11th. We’ve continued to bring the awesome in Nu and have had help from quite a few people including Bil Simser (@bsimser), MIchael Carter (@kiliman) and Brendan Erwin (@brendanjerwin).

Over the next few months we are going to see a transition in the community. Certain people out there are not going to be happy about Microsoft entering the package management market, but most people I have spoken to think it will ultimately make the community better. I think most of us have the same opinion. It’s about frickin’ time. And with Microsoft behind it, the possibility for you and I to get our open source tools into the hands of the .NET community at large will make the community better!

Heartland Developer Conference 2010

Rob Reynolds — Tue, 14 Sep 2010 22:04:36 GMT

Recently I was able to attend and speak at Heartland Developer Conference (HDC). This was my first time at the conference and it went smoothly for me. I was able to attend most of the sessions and had a great time!

I had a session on Database Change Management w/RoundhousE! It went really well, I was very relaxed although I only had 45 minutes to talk. One item of feedback I got was that I didn’t seem interested in what I was talking about. It was just that I was very relaxed having practiced and prepared. I spoke very matter of fact about the tool. And I’ve been using it for over a year now, so it’s hard to fully remember the pain I had before and how much of a relief RoundhousE really is! Here is the slide deck and sample (in 7zip format).

This was a great event and I would encourage anyone to get out next year and check it out!