Rob Reynolds - The Fervent Coder : Gems, Tools

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.

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

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

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

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

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

cinst windirstat

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

A picture is worth a thousand words in this case:

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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

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

References

http://chocolatey.org/

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

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

http://twitter.com/chocolateynuget

Videos

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

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

Blog Posts

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

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

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

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

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

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

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

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

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

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

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

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

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

The Evolution of Package Management for .NET

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

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

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

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

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

Nubular

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

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

Microsoft Introduces Package Management – NuPack

From the front page of CodePlex “NuPack is a free, open source developer focused package management system for the .NET platform intent on simplifying the process of incorporating third party libraries into a .NET application during development.” NuPack is a collaborative project in the Outercurve Foundation. It is an Open Source Project, and truly the first of it’s type, with Microsoft Employees working full time on it and open source developers contributing at the same time. The core team is not just Microsoft and that means the tool will have the influence of the community at large. This means that like the Orchard Project, you or I can contribute. Unlike the Orchard Project, you and I have an opportunity to contribute core features (given that the right conditions are met).

This is NOT the same Microsoft

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

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

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

Why is This Good For the Community?

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

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

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

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

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

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

What is the Future of Nu?

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

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

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

Thank You

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

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

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

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!

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)!