Rob Reynolds - The Fervent Coder : UppercuT

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!

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!

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

The Future of .NET Open Source Software Delivery

Rob Reynolds — Mon, 26 Jul 2010 18:57:00 GMT

Imagine we are awhile into the future. How do you get open source releases down to your project so that you can use them? How do you get the products down to your computer so that you can use them? Is it easier or harder than the way we’ve always done it before?

The Past and Present

Before we can go there, let’s look at what we do now (the past is really the same for us here). Let’s say I want to use NHibernate. What do I do? There are basically three paths we all follow in this process.

1. Never had product x before. If I don’t have a current version, I have to go out and look for it. So what do I do?

Open a browser
Find the site
Find the downloads
Find the particular download I want through the plethora of options that may be presented to me
Download it
Unzip it
Then put it into my project references folder somewhere so I can keep it in source control with my project

2. Use the current version without upgrade. If I have a current version, I may just copy it over and use it in my new project. Nevermind that it is two versions ago. I don’t want to take the time to upgrade because it could be a pain.

Open file explorer and find the project with the old version
Open file explorer and find the new project
Create the structure I need for the references folder
Copy the contents of the old project to the new project

3. Upgrade. If I find a bug or I decide it’s time to upgrade to a newer version, how do I get it? Repeat the process of #1 (Never had product x before) and getting the latest version.

Problems with the Present Method of Delivery

It's slow. How long did it take me to get all of that? Yeah, now multiply times every library I want to use.

Too many decisions. I have to make way to many decisions to get the right product and right version downloaded and referenced into my project.

Dependencies may be hard to manage. I may be using projects that depend on the same libraries. In the example above I am using Castle in my project. That got upgraded as well when I got the latest version of NHibernate. Now I may have to test the changes to that. What if the latest version of Castle Windsor I am using is not compatible with the latest version of NHibernate? I won’t see that issue necessarily until I try to run my code. I can try binding redirects, but there is no guarantee that that will work. So now I have a problem. I have to figure out what version of Castle Windsor to use so that I can use the latest version of NHibernate. And this is where dependency management is fully placed on me as a developer. I can now decide to move forward or just continue to use the old version.

Too easy to just continue using the same version you have. It's way too easy to keep using the version you first downloaded and never learning about all of the awesomeness that comes with more current versions of the product.

Unfortunately for a lot of people, what I just mentioned with projects that have dependencies on the same things as other projects is the biggest barrier to using OSS (Open Source Software). So let’s talk about the future.

The Future

So now that we have looked at how we currently do it, how will it be in the future?

Open source developers will publish their latest releases to a central repository (possibly in addition to other methods of offering releases). Then everyone can get their latest releases and develop from there.

Same three scenarios.

1. Never had product x before. Here’s the process.

Know what I’m looking for and confirm the name at the central repository
open a command line
type something to the effect of nu install nhibernate

And I’m done. It’s all brought to me and sitting in my references folder of my project.

2. Use the current version without upgrade. This is still an option. Same as in the present described above.

3. Upgrade. Here’s the process.

open a command line
type something to the effect of gem update
type something to the effect of nu install nhibernate

What Issues Does the Future Method of Delivery Address?

Speed. The process is amazingly streamlined. We are talking seconds as compared to minutes of time to get something. I can now concentrate on what I want to do instead of spending all the time I was on just getting the packages I needed.

The decision tree is reduced. How many decisions did I have to make to get what I needed in the present scenario? How about the future scenario? Greatly reduced. Less choices to get what I want actually gets me to a decision faster.

I immediately see the dependency changes. All of the dependencies that are required come along nicely with NHibernate. I can immediately see that it downgraded my versions of Castle Core and Dynamic Proxy2. So now I know immediately that I have a problem between Castle Windsor and NHibernate using different versions. It doesn’t solve my problems on this, but it brings it to the surface. So now I can try something like the aforementioned binding redirects.

The process of upgrade became easier than use the current. Another thing you may have noticed. It actually becomes easier to upgrade to the latest version as compared to #2 (Use the current version). That will move people to upgrade, because people will choose the easiest path to get them on their way. And when everyone using the latest version, everyone wins.

The Future Is Now

Oh yeah, the future? It’s now. http://groups.google.com/group/nu-net

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)

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

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.

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!

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?

Chicago Alt.NET Presentation Aftermath

Rob Reynolds — Sat, 15 May 2010 21:29:50 GMT

Right now I’m on the train on my way back from Chicago. It’s interesting to be drinking a Corona and hanging out in the lounge while I’m watching the miles go by. Chicago was a nice time. I had never been so we decided to vacation in Chicago and see the sites – posts coming at the other blog.

My presentation was on UppercuT. It was a small group that came to the presentation which makes for an more engaging audience. Overall it was a pretty good presentation and I enjoyed it. We got a little comfortable and ventured off track for a few minutes and talked about RoundhousE as well. I would definitely come back out to Chicago and present or go to a Code Camp.

The slides for the presentation are here: presentation slides.

I had a good question that came about when working on Open Source. I’ll catch that in the next post.

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…

Rob Reynolds - The Fervent Coder : UppercuT

Published Applications AKA _PublishedApplications

Remember Our Old Friend _PublishedWebsites?

Introducing _PublishedApplications

PublishedApplications Is On NuGet

Want A Demonstration?

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

Most Creative From Zero To Deployed Contest Extended!

And The Winner Is…

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!

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

UppercuT v1

Builds On Linux

Multi-Targeting

Semantic Versioning

Gems Support

Nitriq Support

UppercuT v1.1

Obfuscation

Closing

Herding Code Talks About Nu

The Future of .NET Open Source Software Delivery

The Past and Present

Problems with the Present Method of Delivery

The Future

What Issues Does the Future Method of Delivery Address?

The Future Is Now

Related Posts

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

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?

Chicago Alt.NET Presentation Aftermath

UppercuT and Mercurial (hg)

Chuck Norris Welcomes You

What is the Chuck Norris Framework?

What’s in a Name?

Call To Action