AutoMapper upgraded to .NET 4 and VS 2010

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:

image

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:

image

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:

image

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:

image

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.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in AutoMapper. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • ahjohannessen

    When you merge the dll, do you make external dependencies internal? I had a problem this morning with Castle.* versioning because of Castle.* usage elsewhere in my code.

  • http://www.codebork.com/ Alastair Smith

    Out of interest, why did you choose not to create the NET35 branch locally and push that out to GitHub?

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @ahjohannessen

    Yep, you have to internalize at least a lot of things. Pull down the source and you can see how I got it to work. But I also deploy the non-merged versions, in case folks need a later version of Castle or something

    @Alastair

    I didn’t think that a local branch could be pushed to a remote server branch that doesn’t exist yet. Is that possible?

  • http://www.charlesstrahan.com Charles Strahan

    Nice post, Jimmy.

    in general, the `:’ separates the “source” from the “destination”, so `git pull origin foo:bar’ will pull the “foo” branch down from your remote, while naming it locally “bar”; whereas `git push origin bar:foo’ will push your local “bar” branch to your remote as “foo”.

    You can also delete a remote branch by doing `git push origin :foo’, which will delete the foo branch (it essentially says “push nothing up to my remote origin as ‘foo’” – Yoda speak for “delete foo”).

    You may already know most of that, but I figured I’d share. GitHub has a good reference here:
    http://help.github.com/remotes/

    -Charles

  • http://coderjournal.com Nick Berardi

    I think you used a round about way to actually create a branch.

    http://learn.github.com/p/branching.html

    because you can do

    git branch NET35
    git checkout NET35
    … do some git stuff and commit …
    git push origin NET35

    to me that seems more straight forward then the method you took.

  • Allen Firth

    do you support mapping from dynamic (.NET 4.0) objects in the latest version of AutoMapper?

    • Anonymous

      Nah, not yet.

  • Pingback: How to install Automapper for .net 3.5 | FaceColony.com - Developers Network