In one picture:

In Hg, branches are metadata included in each changeset.  In the operation above, I created a branch, but that only marked the current directory with a branch name.  The branch won't actually show up unless I make a commit.  In fact, if I checkout to another revision, it's as if the "hg branch" command never happened.  When I list the branches, you won't see this new branch name.  The name in the PS window just comes from the PowerShell-Hg extension being smart.

One implication is that our team has to make phantom commits for the branch to officially "show up".  You start to see commits like "phantom commit" early on, then later they start saying "stupid commit".  It's the only way we could get a branch to show up locally and on the server.

In Git, a branch is nothing more than a pointer to a commit, and the commit itself carries no information about a branch name.  A much more flexible model in my experience.

This hit me today when I wanted to move a set of commits to a different branch, which turned out to be very difficult as the branch name was embedded in to the commit names.  Rebasing helped, except that the commits were already pushed to the server.  We wound up having to back out of the commits, even though these were on a different logical branch, simply because our build server got confused about these extra commits that were marked with the wrong branch name.

Perhaps Hg branches aren't broken and this design is intentional.  But it's annoying and less powerful and flexible than Git's more simple model, of just a pointer to a commit.

Side note for the Git folks – I've also wasted 2 hours of my life on Git when my .git folder suddenly went empty – and not from me accidentally deleting anything.  Lost all my dangling topic branches on that one.

In the last post, I posed the question on what to do with .NET framework upgrades and OSS support.  I wanted to upgrade AutoMapper to .NET 4, but I didn't want to leave a lot of folks behind because their project isn't .NET 4.  I had a couple of choices:

• Call the last release (1.1) the last official .NET 3.5 release
• Branch it and allow both to live side-by-side

Since option #2 didn't really cause me much extra overhead, I went for that one.  To upgrade, I first needed to create a remote branch on github:

Creating a remote branch in git is a little esoteric, as for the most part, git wants to be local.  To create this remote branch, I just ran:

• git push origin origin:refs/heads/NET35

More than a little esoteric, but whatever.  To then start using this remote branch, I needed to create a remote tracking branch to make it easier to push and pull:

• git checkout –track –b NET35 origin/NET35

And now my local repository has both remote branches being tracked:

With both branches going, I now set about upgrading the AutoMapper to .NET 4.

Upgrading the project

Upgrading the AutoMapper code to VS 2010 and .NET 4 was easy enough.  I just opened the VS 2008 solution in VS 2010, and the upgrade wizard properly upgraded everything.  Upgrading the solution files does not change the target framework, so I still needed to modify all of the project files to target .NET 4:

That was easy enough, and all tests immediately passed.  I decided to leave the Silverlight 3.0 projects out of the equation, I still need a better way to support multiple runtimes easily.  Some of the app.config files were automatically modified, but there were really no problems upgrading the actual projects to .NET 4.

Upgrading the build, however, was a completely different story.

Upgrading the build

Most of the build tools I used, including NUnit and psake, were still targeting .NET 3.5.  To upgrade these, I first needed to download the latest psake and include the following configuration in my build script:

$framework = '4.0'

This told psake to use the .NET 4 framework.  Next, I needed to tell NUnit to target the .NET 4 framework.  I was able to do this by adding the "supportedRuntime" element:

<startup>
    <requiredRuntime version="v4.0.20506" />
</startup>

I stuck this in my "nunit-console-x86.exe.config" file, where it already had a commented-out section for me to edit.

The last part I needed to fix was the ILMerge call in my build script.  This was much trickier.  I needed to modify the call to ILMerge to include the path to the .NET framework.  Previously, I only needed to include the version.  I created a PS function to get the framework directory:

function Get-FrameworkDirectory()
{
    $([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
        .Replace("v2.0.50727", "v4.0.30319"))
}

Quite lame, as I get the current runtime path and replace the folder name of the .NET 2 version number with .NET 4.  I'm sure there are better ways, but hey, it works.

Finally, I just created a property to hold this value:

$framework_dir = Get-FrameworkDirectory

And modified the call to ILMerge to include this value:

ilmerge.exe /targetplatform:"v4,$framework_dir"

Once all that was done, I created a second build on the TeamCity CodeBetter build server:

That's pretty much it.  It was a little hairy upgrading the build, but that's only because of the tools I use.  If I didn't have Stack Overflow, it would have been much more difficult :)

Support

The idea going forward is to apply pull requests and bug fixes to the .NET 3.5 branch, but not any new feature work.  I'm not going to delete that branch, so anyone wanting to add new features just needs to fork that branch and send pull requests.  Because branches are so easy to manage in github, there's really no reason for me to just kill the .NET 3.5 version.

Otherwise, I'm getting started on the master branch on version 2.0 work.  For those that have forked master and want to now point to the NET35 branch, you can just update your local upstream remote to point to the different branch.

Update: Much to my embarrassment, I forgot to mention OpenRasta!

I've received quite a few questions in the past months and year about web frameworks for .NET (some confusion around the difference between WebForms, ASP.NET MVC, FubuMVC, ASP.NET in general, etc).  So I thought I'd make a quick blog post giving some real basic explanations of these frameworks, what the intended audience is for each, and what the strengths and weaknesses are of each.

Note: This is not an exhaustive list. It does not include all the frameworks that are out there. There are many good ones for .NET each with their own particular take on the matter. If you're shopping for a framework, please do your research and only consider this post as one of many resources.

ASP.NET

ASP.NET is more of a foundational framework. I wouldn't recommend developing a whole app directly against ASP.NET itself. All the frameworks mentioned below are built on TOP of ASP.NET and provide greater convenience and accelerators for making web development easier.  While it is possible to build an entire web application directly using ASP.NET HttpModules and HttpHandlers, I wouldn't recommend it. It's somewhat similar to doing Assembly language programming, but for the web.

Knowing and being familiar with the libraries, services, and facilities that ASP.NET provides is critical for doing development with any of the frameworks mentioned below.  So I highly recommend that you study ASP.NET, read documentation, examples, articles, and books on the subject.

ASP.NET Web Forms

ASP.NET Web Forms was developed at the same time as ASP.NET and was meant to be the primary framework for developers moving from VB6 and ASP (VBScript/JScript) development to the .NET framework.  Web Forms was intended to make web programming a familiar experience for VB6 developers who were used to Windows application event-driven development (i.e. Button1_Click events) and who were used to building user interfaces on designer surfaces by dragging and dropping controls.  Web Forms has some strengths in that it's been around for awhile, it's fairly comprehensive, and it's approachable for many developers.  While you might at first thing that this is a strength, Web Forms' greatest weakness is that it too abstracts the developer from the underlying realities of stateless HTTP-based web development.  Many critical aspects of web development are managed for the developer (sometimes in sub-optimal ways) leaving the web developer into problems when trying to anything outside of the normal Web Forms development path.

Web Forms has its place (for example, in small IT shops where the developer isn't a full-time developer and just needs to quickly assemble a forms-over-data application).  For any serious web development effort, however, I would consider the friction and hand-tying effects of Web Forms too great to bear and so therefore I don't recommend Web Forms for most development scenarios for .NET.

ASP.NET Web Forms is commercial closed-source, built by Microsoft and is still under active development. However, development has slowed recently in favor of the newer ASP.NET MVC framework.

Castle MonoRail

Castle MonoRail is an open source framework that was built, in large part, due to frustrations that web developers in .NET experienced with Web Forms – especially after having worked with several non-.NET frameworks and seeing how much easier many tasks were to perform.  MonoRail is still actively maintained and there are many production deployments using it as the core web framework. MonoRail can use various "view engines" including the "Web Forms" view engine, Brail, NVelocity, and others.  Its strengths are that it is a comprehensive framework, it fits well within the whole Castle family of projects, and allows for much more freedom than Web Forms.  It's weaknesses include being fairly different from other forms of ASP.NET-based development (which some might consider a strength, so weigh this for your own team), and it has heavy dependence upon other Castle frameworks (which may not be an issue for all teams, but for some it is). 

In the interest of full disclosure, I admit that I don't personally have a lot of experience with MonoRail so I cannot effectively discuss it's strengths and weaknesses.  I know that many colleagues, whom I respect, use MonoRail with great effectiveness. So it is a serious contender and worthy of investigation if you are shopping for a web framework.

MonoRail is open source (contributions welcome).  It is under active development.

OpenRasta

OpenRasta is an open source framework. Their doc page explains it best when it says, "OpenRasta is a resource-oriented framework for .NET enabling easy ReST-ful development of web sites and services."  OpenRasta however does have many MVC features and can serve as a full-fledge web application framework (i.e. it's not *just* a REST framework).  OpenRasta's strengths lie in it's comprehensiveness, wide range of features, active development and support community plus good documentation. OpenRasta's weaknesses are similar to other frameworks in that is not as approachable as Web Forms and is intended for experienced developers. 

Also in the interest of full disclosure, like MonoRail, I don't have a lot of personal experience with OpenRasta and so I cannot effectively discuss it's strengths and weaknesses.  Please investigate for yourself and engage the OpenRasta community for more information.

ASP.NET MVC

ASP.NET MVC is another framework built on TOP of ASP.NET (but not on top of Web Forms – MVC is parallel to Web Forms).  ASP.NET MVC was developed by Microsoft in response to complaints of .NET web-based developers who complained about design problems with Web Forms.  While you can mix Web Forms and MVC development in the same project, I wouldn't recommend it unless there was a specific need to do it.  MVC does away with the cumbersome "Page Control Lifecycle" of Web Forms and provides a much more stream-lined approach to web development.  MVC is much closer to the inherent stateless request/response nature of HTTP and so therefore makes it much easier for experienced web developers (and even inexperienced ones) to develop complex web applications.  MVC is less focused on designer-based drag-and-drop programming and more on code-centric programming.  There sometimes is confusion about the difference between ASP.NET MVC and Web Forms because MVC can use *some* parts of Web Forms for presentation.  This is known as the "Web Forms View Engine". There are also other view engines for ASP.NET MVC including Spark and Razor.  This allows you to use ASPX and ASCX files and some runat="server" controls in your views, but without having to have code-behind files and Page Control Lifecycle event handling.   MVC's strengths are similar to MonoRail in that it's fairly comprehensive, and allows a lot more freedom of development and puts the developer back in touch with the fundamentals of web/HTTP programming.  It is well documented and has many guides and a great user community around it.

It shares the same weakness as MonoRail in that MVC is less approachable for less experienced developers.  For more experienced, advanced developers, certain design aspects of MVC can be cumbersome (such as the use of too much inheritance, problematic support for dependency injection and IoC tooling, and too much friction when writing unit tests). These weaknesses are not critical, however, and many good developers are using ASP.NET MVC quite effectively.  ASP.NET MVC is a good contender if you're investigating frameworks and definitely worth some time to spike out some examples.

ASP.NET MVC is commercial open-source (contributions are not accepted, but you can view the source). It is currently in active development by Microsoft and is on its 3rd version.

FubuMVC

FubuMVC is another framework built on top of ASP.NET and sits at the same level ("competes" with if you will) Web Forms, MonoRail, and ASP.NET MVC.  FubuMVC was originally designed in response to the perceived issues (identified in the preceding section) with ASP.NET MVC.  The original designers felt that ASP.NET MVC was good, but didn't go far enough in certain areas to be truly great. FubuMVC uses various view engines like ASP.NET MVC and MonoRail. Currently FubuMVC supports Spark and Web Forms view engines and a Razor engine is being considered.  FubuMVC's strengths include being more IoC/DI and SOLID friendly than ASP.NET MVC.  It's more compositional (versus inheritance-based) which allows for greater freedom for the developer. FubuMVC also has greater support for conventional development saving developers a lot of time in both development and testing by standardizing the aspects of their application that are similar. FubuMVC's weaknesses include the same approachability issue that MonoRail and ASP.NET MVC, but I would say FubuMVC fairs worst in this regard. FubuMVC is designed for advanced, experienced developers.  FubuMVC also has a sore lack of documentation and guides at the moment.  FubuMVC is also not as comprehensive as ASP.NET MVC and MonoRail.  In some respects, FubuMVC has more functionality, but in (many) other respects it still has a ways to go.  Though FubuMVC has a small development team currently, but is gaining ground steadily and growing.

FubuMVC is open source (contributions welcome).  It is under active development.

It doesn't matter how much experience you have, what your title is, or whether you are considered a leader in the team / project / company. If you don't know yourself and when you need to ask questions, you're going to be in trouble. You must be able to evaluate your own perspective and whether or not you are stuck down in the weeds or not.

I'm mapping individual trees, not surveying the forest

I just got off the phone with a coworker who is the 'point person' on a new feature set. I called him and asked for advice on two separate issues related to the piece that I am currently working on. 1) a design problem with the workflow, and 2) whether or not i should "do it right" or "get it done".

My own perspective and involvement in the process had led me down into the weeds of implementation detail where I needed to be. I recognized an issue in the implementation that was causing problems with the workflow. I also recognized that my current depth and focus were preventing me from seeing the big picture (schedule, budget, etc). My reaction to the design problem was one of "do it right" because I was focused entirely on the implementation issues at hand. I knew that I needed a higher level perspective to understand whether or not "do it right" was the correct response, though. So, I called up my coworker and asked for help. We discovered two possible solutions through the conversation. One of them was "the right way" to make the code conform to all of the principles and patterns that we try to use. The other was "well, you could just do this and get it done without a major rewrite", ignoring many of those principles.

Lose the ego and the pride

In the end, I was not capable of making the decision to "do it right" or "get it done" because I was too far down in the weeds of implementation detail. I needed a different perspective and advice on how to proceed and I found that perspective by asking questions and seeking advice. 

I don't care about my title, role, or over-arching responsibilities on the team, the project or within the company. It would have been irresponsible of me to assume that I could make the decision on my own at that point in time. This does not mean that I always have to seek advice and others' perspectives. It only means I know when I need to seek advice and others' perspectives. It also creates opportunities for me to take the opposite role on a regular basis. I am often the person with the high level perspective who is capable of providing advice on whether or not someone else can take the time to "do it right" vs "get it done". And because I know when to ask and I do ask when I need to, others are also willing to ask because they see that it's ok to ask.

If you refuse to ask; if you don't know when to ask; if you are afraid to ask; you are potentially damaging your career, team and project. Lose the ego, drop your guard and give up your pride for a moment. Learn when and how to ask for the help that you need.

I have a few blog posts queued up that relate to the product I'm working on for my day job.  The blog posts are generally product-specific and so (I feel) aren't appropriate for posting on this (my Los Techies) blog as it would be crass marketing.  I think that you, dear reader, did not subscribe to this feed to be marketed to, so I won't offend you like that.  If, for whatever reason, you're interested in what I'm working on, or what my company is working on, you can check out my employee blog, or all the Dovetail blogs.

Having said all that, I just posted a recent post that I thought contained a lot of non-product-specific topics that might benefit you when thinking about problems of customizations, upgrades, frameworks, etc.  So if you can overlook a few mentions of my product, I think the rest of the blog post may be beneficial to you. You can read it here:  Upgrade-Safe Customizations.  Please let me know if you disagree with my assessment.