Rob Reynolds - The Fervent Coder : Development

this.Log– Source, NuGet Package & Performance

Rob Reynolds — Thu, 20 Dec 2012 05:24:08 GMT

Recently I mentioned this.Log. Given the amount of folks that were interested in this.Log, I decided to pull this source out and make a NuGet package (well, several packages).

Source

The source is now located at https://github.com/ferventcoder/this.log. Please feel free to send pull requests (with tests of course). When you clone it, if you open visual studio prior to running build.bat, you will notice build errors. Don’t send me a pull request fixing this, I want it to work the way it does now. Use build.bat appropriately.

To try to cut down on the version number being listed everywhere, I created a SharedAssembly.cs (and a SharedAssembly.vb for the VB.NET samples). That helped, but it didn’t solve the problem where it was in the nuspecs as dependencies. So I took it a step further and created a file named VERSION. When you run the build, it updates all the files that contain version information. Having one place to handle the version is nice.

NuGet

When moving this.Log to a NuGet package (or in this case 9 NuGet packages), I was able to play with some features of NuGet I had not previously, symbol servers and packing a csproj. With packing a csproj, I was able to quickly (well mostly) set up the build to package up every project with NuGet packages.

All packages can be found by searching for this.log on NuGet.org.

this.Log Logging Extension – does nothing by itself except brings the LogExtensions and this.Log.dll. You need to install one of the plugins to get this.
this.Log Logging Extension (log4net Plugin) – the log4net plugin to this.Log
this.Log Logging Extension (log4net Plugin) SAMPLE – this is a sample showing how this.Log-log4net works in action. Add it to a console application.
this.Log Logging Extension (log4net Plugin) SAMPLE for VB.NET – same as the previous sample, except for VB.NET
this.Log Logging Extension (NLog Plugin) – the NLog plugin to this.Log
this.Log Logging Extension (NLog Plugin) SAMPLE – this is a sample showing how this.Log-NLog works in action. Add it to a console application.
this.Log Logging Extension (NLog Plugin) SAMPLE for VB.NET – same as the previous sample, except for VB.NET
this.Log Logging Extension (Rhino Mocks Plugin) – MockLogger for Rhino Mocks
this.Log Logging Extension (Moq Plugin) – MockLogger for Moq

NOTE: If you’ve installed any of these prior to this post, you will want to uninstall and reinstall them (there was an particular issue with the version on the Rhino Mocks version). I’ve fixed and updated quite a bit on them from version 0.0.1.0 to 0.0.2.0.

Performance

Performance testing with log4net showed this only has an overhead of 42 ticks tested over 100,000 iterations. That’s a pretty good start given that it has a reflection hit on every call.

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.

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

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.

Herding Code Talks About Nu

Rob Reynolds — Fri, 27 Aug 2010 06:22:58 GMT

Dru and I were recently featured on Herding Code Podcast. In the podcast we talk about everything from package management in general to Nubular (Nu) to other package management systems (OpenWrap, Bricks, and Horn, although horn was/is slightly different) to the possibility of Microsoft releasing a package management system. It was a good time and I enjoyed doing the podcast, but the herding code guys start recording at an insane 10:30 PM! I have no idea how I made it through the whole thing and was still able to talk afterwards.

Some highlights:

There is a lot of talk in the beginning about package management in general.
Basically, I say the word “basically” way too much.
For the first 16 minutes I think I was teetering on sleep, it was 10:30PM after all. Then after that I start to wake up and sound more articulate.
Big shouts out to all the people in the community that have really been stepping up, and huge shout outs to Nick Quaranto (@qrush), Bil Simser (@bsimser) and Michael Carter (@kiliman).
40:16 – Discussion about what we would do if Microsoft released a package management system
49:34 - “It’s spelled with an N U” - Dru Pimps Nu in the “Pimp Your Code” section of the podcast
Going OT (off topic) 53:11 - “We junk punch audit” - Mentions for RoundhousE and what problems it solves.
55:13 - “At the end of the day it is what it is as long as you bring your A game” - Basically Rehashed and Remixed.

Check out the herding code podcast and notes for more. I didn’t keep track of certain times for interesting bits in the beginning of the podcast, but Ben Griswold does an excellent job on the notes from the podcast.

http://herdingcode.com/?p=272

How To – UppercuT and Gems

Rob Reynolds — Tue, 20 Jul 2010 14:00:00 GMT

In a previous post I mentioned how I was going to show you how UppercuT (UC) has the ability to make gems stupid simple to create and publish. You ask if gems can get any easier and to that I answer, “Why YES, they can!” How about just filling out the information for the gemspec, running a build and having a nice, shiny new gem ready for publishing?

Rock The Gems

Basically you want to get the latest release of UppercuT. You can download it or grab the source and compile.

There are already instructions out there for how to get UC in your project, so I’m not going to concentrate on that.

Once you upgrade (or add and get everything else set up), you want to have this gems folder at your top level (just under trunk or branch name).

In that gems folder you are going to find a file named something like the file below. Rename that file to your new gemname.gemspec.

Note: Once you have a gemspec file in a gems folder, your build server NOW needs to also have ruby and gems installed.

Open that file in your favorite text editor and fill in the details. Here’s a good post on how to do that.

Then just for having the gems folder with a gemspec in it, UC will automatically try to build the gem for you (the code in your code_drop/projectname folder is brought over to code_drop/gems/lib folder).

Removing All of the Other Output After the Gem is Built

Once we are good with what we are getting back for the gem, we can start cleaning up. So we go into our build.custom (don’t have one? create it right next to the build folder) folder and create a file named gemsBuild.post.step.

Let’s open the file and insert this:

<?xml version="1.0" encoding="utf-8"?>
<project name="CUSTOM POST GEMSBUILD" 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="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.to.toplevel}\${folder.code_drop}" overwrite="false" />
  <property name="folder.gems" value="gems" overwrite="false" />
  
  <target name="go" depends="run_tasks" />
  
  <target name="run_tasks">
    <delete>
      <fileset basedir="${dirs.drop}/${folder.gems}" >
        <exclude name="*.gem" />
        <include name="**/*" />
      </fileset>
    </delete>
  </target>
  
</project>

Note: Don’t like NAnt? You can also use Ruby or PowerShell instead of NAnt to write your custom extensions.

Now when we run our build again, we have a nice clean folder.

What If I Want to Change What Goes Into my Gem?

Interested in influencing what goes INTO your gem in the first place? That’s a pretty good thing to be concerned with so that you don’t have all of your referenced assemblies sitting in there. Read about how to set up dependencies. Then you will create a file next to gemsbuild.post.step named gemsPrepare.post.step.

In that file, you will insert something similar to the following (roundhouse file):

<copy todir="${dirs.drop}\${folder.gems}\lib">
  <fileset basedir="${dirs.drop}\${folder.gems}\lib\MSBuild">
    <include name="**/*.*" />
  </fileset>
</copy>

<copy todir="${dirs.drop}\${folder.gems}\lib">
  <fileset basedir="${dirs.drop}\${folder.gems}\lib\NAnt">
    <include name="**/*.*" />
  </fileset>
</copy>

<delete>
  <fileset basedir="${dirs.drop}\${folder.gems}\lib" >
    <include name="ConsoleApp/**" />
    <include name="MSBuild/**" />
    <include name="NAnt/**" />
  </fileset>
</delete>

Learn More

With this knowledge, you shall build. Interested in more UppercuT? Check out the ChuckNorris framework and join the group.

Before you comment about “cluttering” the ruby community, please be sure to read this (we’re with you on this): http://devlicio.us/blogs/rob_reynolds/archive/2010/07/19/gems-for-net-community-response.aspx

Gems - Package Management for .NET

How To – Gems & .NET & How To – Gems & .NET - Dependencies (References)

The Future is Now!

How To – Gems And .NET – Dependencies (References)

Rob Reynolds — Sat, 17 Jul 2010 13:04:00 GMT

In my last post I didn’t mention dependencies. Dependencies are their own animal. They require a couple more things to be in place. Let’s talk about those things.

In the .NET world, the dependency for compiled bits is usually an exact version of a reference.

Let me explain. So for example, you have a reference to log4net, and you don’t ILMerge it into your assembly. You now have a dependency that the DLL needs to be there and a particular version (outside of redirecting the bindings). So what I’m getting at is that you require an exact version of a particular DLL. And what you really need is an exact name, version, culture, and public key token of a DLL. But let’s keep things simple. It’s really the version and the name when culture is neutral (and the key shouldn’t change in the same version). So just the name and version.

Adding a Reference as a Dependency

For each reference you have to a library, you find out what version it is (assembly version) and then add that as a dependency. You can do that by cracking open reflector and taking a look at the actual assembly version.

Don’t use the properties. Neither file version or product version are going to be accurate here:

There is nothing out there that says that assembly, file and informational (also known as product) versions have to be the same. .NET relies on the assembly version for referencing. It makes sense that we should as well. Here’s a better example where things are different:

So what would I put in my gemspec? If your reference was to log4net version 1.2.10.0, then you need to assign a dependency to that exact version. Done like so:

spec.add_dependency('log4net','= 1.2.10.0')

I believe you add each referenced dependency to it’s own line.

Gem Exists?

Now to the sanity check. Before you even add it as a dependency, you want to ensure that the gem exists.

Go to http://rubygems.org and in the top right there is a search box. Search for your reference there.

So let’s search for log4net to be sure it’s there.

Sweet! I can move on to my next reference because the right version of the gem exists.

Keep in mind that the name of the gem may not be the one you are looking for and/or the name may be slightly different. For example. I have a gem for UppercuT. The gem is named uppercutbuild because there was already a gem named uppercut.

Gem Doesn’t Exist?

Now if it’s not there, you can add it. When the actual authors want to start managing the gem, you can just add them as owners so they can push their own gems.

To check the owners of a gem you type:

gem owner gemname

To add someone, according to the gem docs, you issue this command (all on one line):

gem owner gemname --add users.confirmed.email.address.for.ruby.gems@wherever.com

And that’s it.

You see how I am listed as the owner of the log4net gems? I am not really the developer, when I created the gem, I tied it as closely as I could to the apache project and the committers. When those guys are ready to own the gem, I have the specs for both 1.2.9 and 1.2.10 (both are commonly referred to without the last version octet) and I can just add them as owners.

Gems - Package Management for .NET & How To – Gems & .NET

Walkthrough - Create Gems Even Easier With a Conventional Build (UppercuT)!

The Future is Now!

How To - Gems And .NET

Rob Reynolds — Fri, 16 Jul 2010 15:30:00 GMT

In my last post I showed gems being used for .NET. Now let’s talk about How. Most of this stuff I’ve learned over the past two days, so if I have a mistake here or you have a better idea, please don’t hesitate to offer a better solution.

The GemSpec

The Gem::Specification reference is your friend.

In order to create a gem, you need to define a gem specification, commonly
called a “gemspec”.

A gemspec consists of several attributes. Some of these are required;
most of them are optional.

From here you learn what is required and what will just get you there.

Setup

1. Create a folder named gems in your top level source directory.

2. In that folder we are going to put our gemspec and version files. This is where we will store the files in source control (and one of them may become autogenerated).

3. We will bring our gems folder to our compiled source folder after we build. Then we can add in the compiled output.

GemSpec for .NET

1. Create a file named project.gemspec. In our example it is roundhouse.gemspec. This is the most important file for this entire process.

2. Open the gemspec in your favorite notepad editor. Copy the below in and change it for you needs.

version = File.read(File.expand_path("../VERSION",__FILE__)).strip

Gem::Specification.new do |spec|
  spec.platform    = Gem::Platform::RUBY
  spec.name        = 'roundhouse'
  spec.version     = version
  spec.files = Dir['lib/**/*']

  spec.summary     = 'RoundhousE - Professional Database Change and Versioning Management'
  spec.description = 'RoundhousE is a Professional Database Change and Versioning Management tool'
  
  spec.authors           = ['Rob "FerventCoder" Reynolds','Pascal Mestdach','Jochen Jonckheere','Dru Sellers']
  spec.email             = 'chucknorrisframework@googlegroups.com'
  spec.homepage          = 'http://projectroundhouse.org'
  spec.rubyforge_project = 'roundhouse'
end

3. Just about everything with tick marks above you will edit to suit your needs. spec.name and spec.rubyforge_project (and the gemspec file name) should all match and not be an already existing project name on RubyForge.

4. If you are a singular author, instead of spec.authors, replace it with

spec.author = 'somebody'

You can also set up description for multiple lines.

spec.description = <<-EOF
   Rake is a Make-like program implemented in Ruby. Tasks and
   dependencies are specified in standard Ruby syntax.
 EOF

Dependencies On Other Libraries

What we call references. You have a dependency on them existing for your library to run. See this post.

VERSION file

This file is stupid simple. It’s a version number. I believe you can put whatever you want in here. Use the Assembly Version number here and stick with the .NET 4 octets of numbers (like 0.0.0.0) for version.

1. Create a file named VERSION.

2. Open it in your favorite editor and put the version you want here.

Libraries

1. Create a folder called lib.

2. Copy YOUR compiled DLLs into here. Your references (or dependencies) should not go here. See How To: Gems and .NET - Dependencies.

Documentation

Create a docs folder. In that folder goes your documentation. This could be release notes, a ReadMe, actual documentation. This area is open. Just make sure you add the docs folder to the specification.

spec.files = Dir['lib/**/*'] + Dir['docs/**/*']

Executables

If you want to give someone the ability to run an executable from the command line after installing your application with gems, and you use .NET, this is how you do it.

1. Create a folder named bin as a subdirectory next to the gemspec.

2. Put your executable (and dependencies) into the bin directory.

3. Create your shim file (it’s named what you would type at the command line). I’ve called mine rh. The one above allows ruby to be able to actually execute the Windows executable. Let’s open it and see what it looks like. This, we learned from an answer to a post on stack overflow. This shim also goes in source control

result = system(File.dirname(__FILE__) + "/rh.exe " + ARGV.join(' '))
exit 1 unless result

4. Don’t forget that space at the end of your executable name.

5. Open your gemspec. We need to make sure we have spec.executables filled out and our new directory added to our Files.

version = File.read(File.expand_path("../VERSION",__FILE__)).strip

Gem::Specification.new do |spec|
  spec.platform    = Gem::Platform::RUBY
  spec.name        = 'roundhouse'
  spec.version     = version
  spec.files = Dir['lib/**/*'] + Dir['docs/**/*'] + Dir['bin/**/*']
  spec.bindir = 'bin'
  spec.executables << 'rh'

  spec.summary     = 'RoundhousE - Professional Database Change and Versioning Management'
  spec.description = 'RoundhousE is a Professional Database Change and Versioning Management tool'
  
  spec.authors           = ['Rob "FerventCoder" Reynolds','Pascal Mestdach','Jochen Jonckheere','Dru Sellers']
  spec.email             = 'chucknorrisframework@googlegroups.com'
  spec.homepage          = 'http://projectroundhouse.org'
  spec.rubyforge_project = 'roundhouse'
end

Build And Push

You must already have Ruby (1.8.6 or better) and RubyGems installed and/or updated to at least 1.3.7 (gem update –system). You will want to use a RubyInstaller version of Ruby under the Ruby on Windows section.

1. Open a command line and type

gem build project

2. If there are no issues, you should have a gem for upload.

3. Create an account with RubyGems.org.

4. Ensure your project name isn’t already taken by searching for it. If it is you will need to rename your gemspec file, spec.name, and spec.rubyforge_project to a name that is not taken.

5. Type the following command:

gem push project_someversionnumbers.gem

6. Let it finish. Head out to rubygems.org and look at your shiny, new gem!

7. Test it.

gem install project

gem uninstall project

FollowUp

In my next post, I’ll show you how to make it stupid simple. UppercuT will support this feature natively so all you have to do is have a directory called gems (at the top level of your source) with the gemspec. During the build, it will create the VERSION file and copy your output the the lib folder (custom step for bin folder will be necessary). Then it will execute a step that builds the gem. All for the price of “build”. That’s coming up in the next blog post. In the meantime, feel free to ask any questions you have. Stay tuned…

Gems - Package Management for .NET & How To – Gems & .NET - Dependencies (References)

Walkthrough - Create Gems Even Easier With a Conventional Build (UppercuT)!

The Future is Now!

Gems - Package Management For .NET

Rob Reynolds — Fri, 16 Jul 2010 04:27:00 GMT

The Ruby community has enjoyed a great user experience with a package management system they use called Gems. A gem is a package (or a library), compressed with some additional metadata, and can be either source files or binaries. Let’s focus on binary gems. We have the same concept in .NET (DLLs/EXEs). You may have references to other DLLs. When you want to update a reference you are using on a project, you may also need to update its dependencies as well. And so on and so forth. A package management project is meant to help make that easier. It’s actually really hard to explain what gems or package management without just showing you. So take a look here:

I type:

gem install sidepop

And that’s it. It looks and sees that I have a dependency on log4net. Notice how it nicely just pulls down log4net version 1.2.10 as well?

Background

I can count on one hand all of the package management projects that have been started for .NET. Dru Sellers, Chris Patterson, and I have talked about package management stuff from time to time. Dru and Chris have been a part of one project (Nu) that has been started several times to start to answer this question. We’ve participated on the mailing list for HornGet. At one point I casually asked why we couldn’t just use gems. Other people out there have probably stated the same thing. But no one has really carried the idea forward. Until now.

Yesterday Dru asked for a gem-ify feature for UppercuT. We started talking and looking at how easy it is to create a gem. Then we figured out how to make the executables piece work as well. This is where you can install a gem and then call the executable from the command line anywhere and get output. From the thread on ChuckNorris where we talked about this:

Here is something you might find pretty interesting: http://rubygems.org/gems/roundhouse

If you have ruby installed, you can install roundhouse now from the command line:

gem install roundhouse

This gives you the opportunity to type this anywhere:

rh <options>

Why Should I Care?

If you work with Open Source, you know how much of a pain it can be to update your references. You update one library, say NHibernate, and find out that you also need to update your references to Castle. And possibly, you might then need to update your references to log4net. It can be a painful process. This is the start of answering that question.

Why Should I Get Excited?

It sounds like Jeremy Miller among others are getting excited about this. And why not? We’ve been trying to answer the gems question since Ruby made it so easy.

The implications of this are awesome! I still haven’t fully grokked what we’ve just opened up. But it’s huge!

It doesn’t get us all of the way there to updating the references in our source code folder. That’s where projects, like Nu, are going to start showing up that leverage the idea of using the gems infrastructure to get the libraries from the ruby folders to your source code folder. You are going to see UppercuT come back soon with taking care of getting your gem built with the proper version.

This is the start of something very cool.

How To - Gems and .NET and How To – Gems & .NET - Dependencies (References)

Walkthrough – Create Gems Even Easier With a Conventional Build (UppercuT)!

The Future is Now!

Do Story Points Relate to Complexity or Time? Response

Rob Reynolds — Fri, 09 Jul 2010 02:24:57 GMT

I was recently pointed to an InfoQ article titled Do Story Points Relate to Complexity or Time? It mentions that some teams estimate by a matter of complexity versus how long in effort something will take. Mike Cohn, who wrote the original post It’s Effort, Not Complexity, makes some very good points into how people should estimate based on how much time a story will take to finish versus another story. Relative effort, not complexity. The argument here is that complexity should not matter if two stories take the same amount of time to complete.

I thought Mike and the article illustrate some very important points. Effort is different than complexity. The InfoQ story mentions:

Dentist - In a BOX!

Mike gave an interesting example where he compares the two backlog items of licking 1000 stamps and performing a simple brain surgery. According to Mike, despite their vast difference in complexity, they should still be given the same story points because they would take the same amount of time.

I am humbly reminded of the humorous video on the right (Dentist – In A BOX!) when presented with this idea of performing brain surgery. The other part of the story that was great talked about story points being a function of effort, risk and uncertainty (link back to Mike’s original comment):

Perhaps the way to say that is that points are a function of effort, risk and uncertainty, or SP = f(E, R, U). (Call one of those complexity if you want; it’s not important.) The idea is that points are an estimate of the effort involved. Risk, uncertainty, complexity, doubt and other things people have mentioned here can be incorporated BUT only to the extent they affect the expected effort. If something is complex but that complexity will not affect the time to implement the feature, that complexity should not affect the estimate—that was my point with the lists of numbers to be multiplied or added.

I do want to point out what Mike mentioned in one of his other comments:

Thinking of points as a function of Effort, Complexity and Doubt is fine. In my reply above to John I just combined Complexity and Doubt into one thing: Uncertainty.

Points are a measure of how long it will take (effort). How long it will take can be affected by other things and those can influence our estimate. The key is to remember and understand that it is always about time–no client ever cares how hard we had to think, only how long it took.

“No client ever cares about how hard we had to think,only how long it took.” What I believe I am hearing is that Mike is not discounting that there is effort in understanding. Thinking, research, and learning time is still effort, and I think a lot of people miss this important point when they talk about effort. The example provided was a doctor versus a boy on the two tasks. What happens if they are the same person and that person is not a doctor? What if it’s you?! In my mind, that makes a better determination of what developers face when estimating a simple problem versus a complex one.

Let’s explore this idea in more detail. What all goes into the effort required to lick 1000 stamps versus perform brain surgery if you had to do them? Sure the effort of actually performing the task is roughly the same, but the effort to learn how to lick a stamp is significantly less than the effort required to learn how to perform brain surgery. And that I believe more accurately represents what we as developers go through.

To further illustrate, where I work, we also take stories and estimate tasks from those stories. With that I have started including ramp up time as part of the effort for my team as developers. A problem could take 15 minutes for me to code. But it might take me 2 hours to understand what it is that needs to be done. That is not a 15 minute task. That is a 2 hour and 15 minute task. And the effort involved was 2 hours and 15 minutes.

Thoughts?

Deciding On Features For Open Source

Rob Reynolds — Sat, 15 May 2010 23:16:48 GMT

“Open source feature selection is subjective.”

An interesting question was posed to me recently at a presentation - “How do you decide what features to include in the [open source] projects you manage?”

Is It Objective?

I’d like to say that it’s really objective and that we vote on features and look at what carries the most interest of the populace. Actually no I wouldn’t. I don’t think I would enjoy working on open source (OSS) as much if it someone else decided on what features I should include. It already works that way at work. I don’t want to come home from work and work on things that others decide for me unless I’m being paid for those features.

So how do I decide on features for our open source projects? I think there are at least three paths to feature selection and they are not necessarily mutually exclusive.

Feature Selection IS the Set of Features For the Domain

Your product, in whatever domain it is in, needs to have the basic set of features that make it answer the needs of that domain. That is different for every product, but if you take for example a build tool, at the very least it needs to be able to compile source. And these basic needed features are not always objective either. Two people could completely disagree what makes for a required feature to meet a domain need for a product. Even one person may disagree with himself/herself about what features are needed based on different timeframes. So that leads us down to subjective.

Feature Selection IS An Answer To Competition

Some features go in because the competition adds a feature that may draw others away from your product offering. With OSS, there are all free alternatives, so if your competition adds a killer feature and you don’t, there isn’t much other than learning (how to use the other product) to move your customers off to the competition. If you want to keep your customers, you need to be ready to answer the questions of adding the features your competition has added.

Sometimes it’s about adding a feature that your competition charges for, but you add it for free. That draws people to the free alternative – so sometimes that adds a motivation to select a feature. Sometimes it’s because you want those features in your product, either to learn how you can answer the question of how to do something and/or because you have a need for that feature and you want it in your product. That also leads us down the road to subjective.

Feature Selection IS Subjective

I decide on features based on what I want to see in the product I am working on. Things I am interested in or have the biggest need for usually get picked first, with things that do not interest me either coming later or not at all. Most people get interested in an area of OSS because it solves a need for them and/or they find it interesting. If one of these two things is not happening and they are not being paid, it’s likely that person will move on to something else they find interesting or just stop OSS altogether.

OSS feature selection is just that – subjective. If it wasn’t, it wouldn’t be opinionated and it wouldn’t have a personality about it. Most people like certain OSS because they like where the product is going or the personalities behind the product.

For me, I want my products to be easy to use and solve an important problem. If it takes you more than 5-10 minutes to learn how to use my product, I know you are probably going somewhere else. So I pick features that make the product easy to use and learn, and those are not always the simplest features to work on. I work for conventions and make the product opinionated, because I think that is what makes using a product easier, if it already works with little setup. And I like to provide the ability for power users to get in and change the conventions to suit their needs. So those are required features for me above and beyond the domain features. I like to think I do a pretty good job at this. Usually when I present on something I’ve created, I like seeing people’s eyes light up when they see how simple it is to set up a powerful product like UppercuT.

Patches And/Or Donations

But remember before you say I’m a bad person or won’t use my product, I’ll always accept patches or I might like the feature that you suggest. If you like using the products I provide and they solve a problem for you the two biggest compliments you can provide are either a patch or a donation. If you think the product is great, but if it could do this one other thing, it would be awesome(!), then consider contacting me and providing a patch, or consider contacting me with a donation and a request to put the feature in. And alternatively, if it’s a big feature, you could hire me to work on the product to make it even better.

What If There Are Multiple Committers?

In the question of multiple committers, I choose that someone always makes the ultimate decision to select whether a feature should be part of a product or not. But for other OSS project maybe this is not the case. If there is not an ultimate decision maker, then there is the possibility of either adding every feature suggested or having a deadlock on two conflicting features.

So let me pose this question. If you work on Open Source, how do you decide on what features to put in your open source projects? How do you decide what doesn’t belong? What do you do when there are conflicting features?

UppercuT and Mercurial (hg)

Rob Reynolds — Thu, 22 Apr 2010 04:33:30 GMT

I mentioned this awhile back on twitter, but UppercuT (UC) has support for Mercurial for versioning your assemblies.

In the settings file, all you need to do it tell UC to use hg.

When you build your assemblies, they will use the changeset number in the version, and in the informational version, you get the hash, just like you do when using Git.

Pretty sweet. By the way, UC also supports .NET 4.0 as of last week. With this knowledge you shall build.

Chuck Norris Welcomes You

Rob Reynolds — Sat, 17 Apr 2010 14:57:21 GMT

Chuck Norris doesn’t program with a keyboard. He stares the computer down until it does what he wants.

All things need a name. We’ve tossed around a bunch of names for the framework of tools we’ve been working on, but one we kept coming back to was Chuck Norris. Why did we choose Chuck Norris? Well Chuck Norris sort of chose us. Everything we talked about, the name kept drawing us closer to it. We couldn’t escape Chuck Norris, no matter how hard we tried. So we gave in.

Chuck Norris can divide by zero.

What is the Chuck Norris Framework?

@drusellers and I have been working on a variety of tools:

WarmuP - http://github.com/chucknorris/warmup (Template your entire project/solution and create projects ready to code - From Zero to a Solution with everything in seconds. Your templates, your choices.)
UppercuT - http://projectuppercut.org (Build with Conventions - Professional Builds in Moments, Not Days!) | Code also at http://github.com/chucknorris/uppercut
DropkicK - http://github.com/chucknorris/dropkick (Deploy Fluently)
RoundhousE - http://projectroundhouse.org (Professional Database Management with Versioning) | Code also at http://github.com/chucknorris/roundhouse
SidePOP - http://sidepop.googlecode.com (Does your application need to check email?)
HeadlocK - http://github.com/chucknorris/headlock (Hash a directory so you can later know if anything has changed)

Others – still in concept or vaporware

What’s in a Name?

People ask why we choose such violent names for each tool of our framework? At first it was about whipping your code into shape, but after awhile the naming became, “How can we relate this to Chuck Norris?” People also ask why we uppercase the last letter of each name. Well, that’s more about making you ask questions…but there are a few reasons for it.

Project managers never ask Chuck Norris for estimations…ever.

The class object inherits from Chuck Norris

Chuck Norris doesn’t need garbage collection because he doesn’t call .Dispose(), he calls .DropKick()

Call To Action

So what are you waiting for? Join the Google group today, download and play with the tools.

And lastly, welcome to Chuck Norris. Or should I say Chuck Norris welcomes you…

UppercuT – Custom Extensions Now With PowerShell and Ruby

Rob Reynolds — Sun, 14 Mar 2010 01:43:27 GMT

Arguably, one of the most powerful features of UppercuT (UC) is the ability to extend any step of the build process with a pre, post, or replace hook. This customization is done in a separate location from the build so you can upgrade without wondering if you broke the build.

There is a hook before each step of the build has run. There is a hook after. And back to power again, there is a replacement hook. If you don’t like what the step is doing and/or you want to replace it’s entire functionality, you just drop a custom replacement extension and UppercuT will perform the custom step instead.

Up until recently all custom hooks had to be written in NAnt. Now they are a little sweeter because you no longer need to use NAnt to extend UC if you don’t want to. You can use PowerShell. Or Ruby. Let that sink in for a moment. You don’t have to even need to interact with NAnt at all now.

Extension Points

On the wiki, all of the extension points are shown. The basic idea is that you would put whatever customization you are doing in a separate folder named build.custom. Each step Let’s take a look at all we can customize:

The start point is default.build. It calls build.custom/default.pre.build if it exists, then it runs build/default.build (normal tasks) OR build.custom/default.replace.build if it exists, and finally build.custom/default.post.build if it exists. Every step below runs with the same extension points but changes on the file name it is looking for. NOTE: If you include default.replace.build, nothing else will run because everything is called from default.build.
- policyChecks.step
- versionBuilder.step NOTE: If you include build.custom/versionBuilder.replace.step, the items below will not run.
  - svn.step, tfs.step, or git.step (the custom tasks for these need to go in build.custom/versioners)
- generateBuildInfo.step
- compile.step
- environmentBuilder.step
- analyze.step NOTE: If you include build.custom/analyze.replace.step, the items below will not run.
  - test.step (the custom tasks for this need to go in build.custom/analyzers) NOTE: If you include build.custom/analyzers/test.replace.step, the items below will not run.
    - mbunit2.step, gallio.step, or nunit.step (the custom tasks for these need to go in build.custom/analyzers)
  - ncover.step (the custom tasks for this need to go in build.custom/analyzers)
  - ndepend.step (the custom tasks for this need to go in build.custom/analyzers)
  - moma.step (the custom tasks for this need to go in build.custom/analyzers)
- package.step NOTE: If you include build.custom/package.replace.step, the items below will not run.
  - deploymentBuilder.step

Customize UppercuT Builds With PowerShell

UppercuT can now be extended with PowerShell (PS). To customize any extension point with PS, just add .ps1 to the end of the file name and write your custom tasks in PowerShell.

If you are not signing your scripts you will need to change a setting in the UppercuT.config file. This does impose a security risk, because this allows PS to now run any PS script. This setting stays that way on ANY machine that runs the build until manually changed by someone. I’m not responsible if you mess up your machine or anyone else’s by doing this. You’ve been warned.

Now that you are fully aware of any security holes you may open and are okay with that, let’s move on.

Let’s create a file called default.replace.build.ps1 in the build.custom folder.

Open that file in notepad and let’s add this to it:

write-host "hello - I'm a custom task written in Powershell!"

Now, let’s run build.bat.

You could get some PSake action going here. I won’t dive into that in this post though.

Customize UppercuT Builds With Ruby

If you want to customize any extension point with Ruby, just add .rb to the end of the file name and write your custom tasks in Ruby. Let’s write a custom ruby task for UC. If you were thinking it would be the same as the one we just wrote for PS, you’d be right!

In the build.custom folder, lets create a file called default.replace.build.rb.

Open that file in notepad and let’s put this in there:

puts "I'm a custom ruby task!"

Now, let’s run build.bat again.

That’s chunky bacon.

UppercuT and Albacore.NET

Just for fun, I wanted to see if I could replace the compile.step with a Rake task. Not just any rake task, Albacore’s msbuild task. Albacore is a suite of rake tasks brought about by Derick Bailey to make building .NET with Rake easier. It has quite a bit of support with developers that are using Rake to build code.

In my build.custom folder, I drop a compile.replace.step.rb. I also put in a separate file that will contain my Albacore rake task and I call that compile.rb.

What are the contents of compile.replace.step.rb?

rake = 'rake'
arguments= '-f ' + Dir.pwd + '/../build.custom/compile.rb'

#puts "Calling #{rake} " + arguments
system("#{rake} " + arguments)

Since the custom extensions call ruby, we have to shell back out and call rake. That’s what we are doing here. We also realize that ruby is called from the build folder, so we need to back out and dive into the build.custom folder to find the file that is technically next to us.

What are the contents of compile.rb?

require 'rubygems'
require 'fileutils'
require 'albacore'

task :default => [:compile]

puts "Using Ruby to compile UppercuT with Albacore Tasks"
desc 'Compile the source'
msbuild :compile do |msb|
  msb.properties = { :configuration => :Release, :outputpath => '../../build_output/UppercuT' }
  msb.targets [:clean, :build]
  msb.verbosity = "quiet"
  msb.path_to_command = 'c:/Windows/Microsoft.NET/Framework/v3.5/MSBuild.exe'
  msb.solution = '../uppercut.sln'
end

We are using the msbuild task here. We change the output path to the build_output/UppercuT folder. The output path has “../../” because this is based on every project. We could grab the current directory and then point the task specifically to a folder if we have projects that are at different levels. We want the verbosity to be quiet so we set that as well.

So what kind of output do you get for this? Let’s run build.bat

custom_tasks_replace:

     [echo] Running custom tasks instead of normal tasks if C:\code\uppercut\build\..\build.custom\compile.replace.step exists.
     [exec] (in C:/code/uppercut/build)
     [exec] Using Ruby to compile UppercuT with Albacore Tasks
     [exec] Microsoft (R) Build Engine Version 3.5.30729.4926
     [exec] [Microsoft .NET Framework, Version 2.0.50727.4927]
     [exec] Copyright (C) Microsoft Corporation 2007. All rights reserved.

If you think this is awesome, you’d be right!

With this knowledge you shall build.

Rob Reynolds - The Fervent Coder : Development

this.Log– Source, NuGet Package & Performance

Source

NuGet

Performance

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

Update: What Type of Software This Applies To

Software Release Management

The Hope Versus The Force

Why Do Users Use Older Versions?

From the User Perspective

Final Thoughts

RoundhousE–Intelligent Database Migrations And Versioning

What is RoundhousE?

What sets RoundhousE apart from other migrators?

How do I get RoundhousE?

AppHarbor - Azure Done Right AKA Heroku for .NET

Heroku

AppHarbor Enters The Scene

From Zero To Deployed in 15 Minutes (Or Less)

UppercuT v1.2–NuGet Support

UppercuT + NuGet == Can Packaging Get Any Easier?

Upgrading?

New to Uppercut?

Getting Some Nuget-ty Goodness To Your Builds

Conclusion – UppercuT and NuGet – A Good Team!

Herding Code Talks About Nu

How To – UppercuT and Gems

Rock The Gems

Removing All of the Other Output After the Gem is Built

What If I Want to Change What Goes Into my Gem?

Learn More

Related Posts

How To – Gems And .NET – Dependencies (References)

Adding a Reference as a Dependency

Gem Exists?

Gem Doesn’t Exist?

Related Posts

How To - Gems And .NET

Setup

GemSpec for .NET

Dependencies On Other Libraries

VERSION file

Libraries

Documentation

Executables

Build And Push

Related Posts

Gems - Package Management For .NET

Background

Why Should I Care?

Why Should I Get Excited?

Related Posts

Do Story Points Relate to Complexity or Time? Response

Deciding On Features For Open Source

Is It Objective?

Feature Selection IS the Set of Features For the Domain

Feature Selection IS An Answer To Competition

Feature Selection IS Subjective

Patches And/Or Donations

What If There Are Multiple Committers?

UppercuT and Mercurial (hg)

Chuck Norris Welcomes You

What is the Chuck Norris Framework?

What’s in a Name?

Call To Action

UppercuT – Custom Extensions Now With PowerShell and Ruby

Extension Points

Customize UppercuT Builds With PowerShell

Customize UppercuT Builds With Ruby

UppercuT and Albacore.NET