Technical Jargon

Last month I posted about hosting a git server under IIS by using GitAspx. While this is certainly one way to host a git server on windows, I wouldn’t recommend this in a production environment.

An alternative (and somewhat more stable) approach is to use the native implementation of git-http-backend that ships with msysgit along with Apache.

Step 1: Install Git

Firstly you’ll need to install msysgit. The current stable version is 1.7.0.2, but this process should also work with the 1.7.1 beta. Be sure to select Run git from the Windows Command prompt when the installer asks you if you want to modify your PATH variable.

Once installed, you’ll need to tweak the installation slightly. By default, the git http server is located at C:\Program Files (x86)\Git\libexec\git-core\git-http-backend.exe (on x64 systems). If you try and run git-http-backend.exe you’ll get the message that the application couldn’t be started because libiconv2.dll is missing:

In order to fix this, copy libiconv2.dll from C:\Program Files (x86)\Git\bin to C:\Program Files (x86)\Git\libexec\git-core

Now when you run git-http-backend.exe from a command prompt, the application should run and you should see an HTTP 500 server error:

Step 2: Install Apache

Next you’ll need to install the Apache webserver. I’m using the 2.2.16 installer which can be found here. I ran through the installation using the default options so my Apache instance is running on port 80.

If you visit http://localhost at this point you should be greeted with Apache’s standard “It works!” message.

Step 3: Create Repositories Directory

Create the directory where you want to store your git repositores. I’m using C:\Repositories. For testing purposes I created an empty test repository:

You’ll also need to put some content in this test repositor

Step 4: Modify Apache Configuration

Next, you’ll need to modify the Apache configuration file so that it forwards requests to git-http-backend.exe. This is done by editing httpd.conf in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\

At the bottom of httpd.conf, add the following lines:

SetEnv GIT_PROJECT_ROOT C:/Repositories
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAliasMatch \
        "(?x)^/(.*/(HEAD | \
                        info/refs | \
                        objects/(info/[^/]+ | \
                                 [0-9a-f]{2}/[0-9a-f]{38} | \
                                 pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
                        git-(upload|receive)-pack))$" \
                        "C:/Program Files (x86)/git/libexec/git-core/git-http-backend.exe/$1"

The first line tells git where your repositories are located. The second line tells git that all repositories in this directory should be published over http (by default, git will only publish those repositories that contain a file named “git-daemon-export-ok”). The final lines tell apache to route git-specific URLs to the git http server.

Finally, if you want to be able to clone from the server without authentication, then you’ll need to tell Apache to allow anonymous access by adding the following lines into httpd.conf:

<Directory />
  Allow from all
</Directory>

After saving the changes, restart the Apache service.

Step 5: Clone the test repository

Next, clone the test repository that you crated in step 3 by issuing the command git clone http://localhost/Test.git

If all goes well, you should see the following output:

At this point, you can now clone repositories from the server without any authentication.

Step 6: Authentication

If you try to push changes to the repository you cloned in step 5, you’ll receive an error:

This is because by default, you can only pull from repositories anonymously, while pushing requires authentication to be enabled.

Scenario 1: Allow anonymous pushes

Sometimes you may want to allow users to push to your repositories without authentication, for example when using an internal, privately hosted server.

To enable this scenario, edit the config file in C:\Repositories\Test.git on the server and add the following lines to the bottom of the file:

[http]
  receivepack = true

This will allow git to accept pushes from anonymous users.

Note that you’ll have to add this to every repository that you create. I’ll show a nicer way to do this later in the tutorial.

Scenario 2: Anonymous pull, authenticated push

This is the default scenario. Git will only allow users to push if they have been authenticated with apache.

There are several ways to enable user accounts with apache. The most basic is to use .htaccess files, although you can also configure integration with Windows user accounts and Active Directory by using mod_authnz_ldap. Configuring these is outside the scope for this tutorial, but there are plenty of examples on the internets.

Once authentication is set up, you’ll need to ensure that you clone your repositories with the username in the URL, as git will not prompt you for a username by default:

git clone http://MyUserName@mygitserver/Test.git

Git will then prompt you for a password every time that you try to push. You can also hard code the password in the URL (somewhat insecure) if you want to avoid this prompt:

git clone http://MyUserName:Password@mygitserver/Test.git

To make this more secure, you could enable SSL on the server and require authenticated traffic to go over HTTPS. Although configuring OpenSSL with apache is outside the scope for this tutorial, I will point out that once configured, you will need to disable the SSL verification on your git client by running:

git config –global http.sslverify false

If you don’t do this, you’ll get an error saying “error setting certificate verify locations” every time you try to clone/push/pull over HTTPS.

Step 7: A prettier UI

At this point, you should be able to clone, pull from and push to the server. However, creating new repositories requires that you connect remotely to the server and run git init from a command prompt on the server.

A nicer alternative is to use a web-based front for the creation of repositories. For this I’ll be using GitPhpHomepage which is a small collection of PHP scripts that I ported from GitAspx’s ASP.NET-based UI to PHP in order to get it working under Apache.

First, you’ll need to install PHP on the server. I’ll be using the PHP 5.3.3 Windows binaries that can be found at http://windows.php.net/download/. The download page is somewhat confusing, offering both thread-safe and non-thread-safe versions compiled with both VC6 and VC9. For use with Apache 2.2 be sure to select the VC6 x86 Thread Safe zip package. Here’s a direct link.

Unzip the contents of this package to C:\PHP on the server and add this directory to Windows’ PATH environment variable:

Next, rename the php.ini-production file to just php.ini and edit the following settings:

Uncomment and edit the “extension_dir” (about half way through the file) so that it says the following:

extension_dir = "c:\php\ext"

Next, edit your Apache configuration file (C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\httpd.conf) and add the following lines to the bottom of the file:

AddType application/x-httpd-php .php
LoadModule php5_module "C:/php/php5apache2_2.dll"
PHPIniDir "C:/php"

This tells Apache to map .php file extensions to the PHP5 apache module located in C:\php.

You’ll also need to tell Apache to look for index.php as a default index file. This can be done by searching for the lines that look like this:

<IfModule dir_module>    
  DirectoryIndex index.html
</IfModule>

…and changing them to this:

<IfModule dir_module>    
  DirectoryIndex index.php index.html
</IfModule>

Be sure to restart the Apache server once you’ve made these changes.

To see whether this is working, create a file called phpinfo.php in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs and place in it the following content:

<?php phpinfo(); ?>

Now, visiting http://mygitserver/phpinfo.php should display a page containing PHP configuration information.

Now that PHP is configured, download the GitPhpHomepage files from http://github.com/JeremySkinner/GitPhpHomepage and unzip them into C:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs

Be sure to edit the config.php file so that it accurately reflects both the git installation directory and your repositories directory.

At this point, visiting http://mygitserver should display a page where you can view and create repositories:

Pressing the “Create a new bare repository” button will open a dialog where you can create a new repository, including the option to enable anonymous pushes:

Obviously, if you’re thinking of using this on a public-facing server you should enable authentication so that not just anyone can create repositories on your server.

FluentValidation 1.3 is now available for download. Here’s what’s changed:

Silverlight 4 compatibility

The Silverlight build of FluentValidation now targets Silverlight 4 rather than Silverlight 3. The Silverlight build is now signed like the main binaries.

Changes to When/Unless

In previous versions of FluentValidation, calls to When or Unless only applied to the current validator in the chain. For example, if you declare a rule that has two validators and a condition:

public class PersonValidator : AbstractValidator<Person> {
  public PersonValidator() {
    RuleFor(x => x.Surname).NotNull().NotEqual("foo").When(x => x.Id > 0);
  }
}

…then the condition would only be applied to the validator that directly preceded it (in this case, the NotEqual validator).

With 1.3, the default behaviour of When and Unless is to apply to all previous validators in the chain. This is a potentially breaking change. This behaviour is slightly more intuitive, but you can still use the pre-1.3 behaviour if you need to by specifying ApplyConditionTo.CurrentValidator:

RuleFor(x => x.Surname).NotNull().NotEqual("foo").When(x => x.Id > 0, ApplyConditionTo.CurrentValidator);

Minor changes to NotEmptyValidator

The NotEmptyValidator now treats strings that contain only whitespace as empty. Previously, only null or empty strings were considered.

New Test Helpers

New test helpers were added for checking whether a property has a child validator applied to it:

public class PersonValidator : AbstractValidator<Person> {
  public PersonValidator() {
   RuleFor(x => x.Address).SetValidator(new AddressValidator());
  }
}
 
var validator = new PersonValidator();
validator.ShouldHaveChildValidator(x => x.Address, typeof(AddressValidator));

Changes to Cascade

To recap, FV 1.2 introduced the concept of a Cascade Mode which controls how execution of rules should continue when the first rule fails. For example, you could specify a CascadeMode of StopOnFirstFailure:

RuleFor(x => x.Surname)
  .Cascade().StopOnFirstFailure()
  .NotNull()
  .Length(1, 250);

…which would prevent the Length rule from running if the NotNull rule fails. With 1.3, this method has been deprecated in favour of an overload for Cascade that takes an enum value:

RuleFor(x => x.Surname)
  .Cascade(CascadeMode.StopOnFirstFailure)
  .NotNull()
  .Length(1, 250);

This was done for consistency with the other methods for setting the cascade mode (more on this in a second).

In 1.2, the cascade mode could either be set globally (by using the static ValidatorOptions.CascadeMode property) or at the rule level. 1.3 introduces the ability to set the validator cascade mode at the Validator level:

public class PersonValidator : AbstractValidator<Person> {
  public PersonValidator() {
    CascadeMode = CascadeMode.StopOnFirstFailure;
 
    RuleFor(....)
  }
}

Other Changes

• Italian translations of the default error messages are now available.
• ChildValidatorAdaptor is now public
• IAttributeMetadataValidator is now public
• Added a non-generic ValidatorContext class so that validator selectors can be used with non-generic IValidator instances
• The internal model was greatly simplified
• Introduced IErrorMessageSource as a way to abstract the different mechanisms for building error messages. The end result is that the PropertyValidator base class is significantly simpler.
• xVal integration supports custom error messages

What’s coming with FluentValidation 2.0?

The next release of FluentValidation will be v2.0. My current plans for this release are:

• ASP.NET MVC 3 integration
• Major rewrite of the fluent interface to allow for validator-specific options. At the moment, all validators share the same options (eg When, Unless, WithMessage, WithState etc). The new fluent interface will allow options that only apply to some validators.
• Remove ASP.NET MVC 1 integration (MVC2 will still be supported).
• Remove the FluentValidation 1.0 backwards compatibility layer

TeamCity 5 has support for .NET code coverage by using nunit with either NCover or PartCover. However, in order to get this working with the latest version of PartCover (4.0.10705) you’ll need to make a few tweaks to the PartCover installation.

Step 1 – Install or Upgrade TeamCity

Make sure you’re running the latest version of TeamCity (currently 5.1.3) as older versions do not have the code coverage support out of the box.

Step 2 – Install & Tweak PartCover

PartCover 4 can be downloaded from sourceforge. Run through the installer, which will install PartCover to C:\Program Files (x86)\PartCover\PartCover .NET 4.0 (on a x64 system):

TeamCity expects to find a file called PartCover.CorDriver.dll in the installation directory. However, with PartCover 4 this was renamed to PartCover.dll, so in order to get PartCover working with TeamCity, copy PartCover.dll and rename the copy to PartCover.CorDriver.dll

Step 4 – Fix the XSLT Templates

TeamCity seems to have problems rendering PartCover’s XSLT templates. I’ve put together a modified version that seems to work, and also allows you to click an assembly name to view the classes in that assembly. The template can be downloaded from here.

The fixed XSLT template should be placed in C:\program files (x86)\PartCover\PartCover .NET 4.0\xslt

Step 5 – Configure your build

In this example, I’ll be running my unit tests through nant’s NUnit2 task, although this also works if you invoke TeamCity’s nunit-launcher directly as well as the teamcity-specific NUnitTeamCity task.

The “test” target in my nant script looks like this:

<target name="test">
  <nunit2>
    <formatter type="Plain" />
    <test assemblyname="Path\To\MyProject.Tests.dll" />
  </nunit2>
</target>

When configuring your TeamCity build, select “PartCover (2.2 or 2.3)” from the “.NET Coverage tool” section on the “Runner” page. Be sure to correctly set the path to the PartCover installation on the build server:

In this example, my build configuration is set to invoke the “ci” target of my build script which in turn calls the “test”target.

You’ll also need to select the assemblies to include/exclude. These are specified in the format of [assemblypattern]namespacepattern.

For example, to include all assemblies beginning with “MyApp”, but excluding the test assembly, the include/exclude patterns would look like this:

Note that I also specify the path to my custom XSLT template as :

C:\Program Files\PartCover\PartCover .NET 4.0\xslt\Coverage.xslt=>index.html

This tells TeamCity to use the custom Coverage.xslt file when transforming PartCover’s outputs and to store the resulting HTML page as index.html.

Once this is done, you can run a build and look at the results. The summary page will contain a sumary of the coverage, as well as a link and a tab to view the full report:

The resulting code coverage file will look something like this:

Traditionally Git requires the use of SSH if you want to host read/write repositories on a server. While this is certainly possible to do on Windows by running OpenSSH under Cygwin, it isn’t a particularly simple process and does require some familiarity with unix/linux.

However, with the smart HTTP support introduced with with Git 1.6.6 it is now possible to push to git repositories over HTTP. Although the default implementation of the smart http protocol requires the use of apache, there are other implementations available. For example, Grack is a ruby-based implementation using the Rack framework and git_http_backend.py implements similar functionality in Python.

I decided to have a go at putting together a native .NET implementation of git-http-backend using ASP.NET MVC and the excellent GitSharp library. The result is available on GitHub in the imaginatively titled git-dot-aspx (GitAspx) project.

To get started, you’ll need to download the source and compile the project. It is built using .NET 4 and ASP.NET MVC2, so you’ll need Visual Studio 2010 installed in order to open the solution.

Once compiled, create a new web site in IIS and point it at the directory containing the application. Be sure to select the ASP.NET v4 Application Pool.

Next, you’ll need to edit the application’s web.config so GitAspx knows where to look for your repositories. This is done by setting the “RepositoriesDirectory” app setting:

<appSettings>
    <add key="RepositoriesDirectory" value="C:\Repositories" />
</appSettings>

Once configured, browsing to the application will display a list of projects (the default homepage is currently unstyled – I hope to have a nicer UI in place shortly!). Clicking on a project shows the clone URL:

You can now clone, pull and push from this URL:

git clone http://localhost:8080/FluentValidation
echo foo > foo.txt
git add -A
git commit -m "Committing"
git push origin master

It’s probably a good idea to put some authentication in place (eg basic authentication over SSL) so not just everyone can push to your repositories! You can also allow/deny access to specific projects using the standard ASP.NET URL authorization mechanism.

At present, this is only an implementation of the “smart” protocol (which allows both push/pull), but I’m also planning on adding support for the “dumb” protocol to be backwards compatible with older clients.

If you’re a user of distributed source control systems such as Git and Mercurial then you may find it painful having to work with subversion (either at work or for an open source project). Recently I started playing with the excellent hgsubversion extension which allows you to use mercurial as a subversion client.

Assuming you already have Mercurial installed (or TortoiseHg) then you can easily grab the hgsubversion extension by grabbing its source from bitbucket:

cd c:\Projects
hg clone http://bitbucket.org/durin42/hgsubversion

Here I’ve simply cloned hgsubversion in to my C:\Projects directory.

Next, edit your Mercurial.ini file (in your home directory) and enable both the rebase and svn extensions. Note that rebase is distributed with Mercurial so you don’t need to specify a path:

[extensions]
rebase=
svn=c:\projects\hgsubversion\hgsubversion

Now you can clone a subversion repository locally:

hg clone svn+https://path/to/someproject/svn/trunk someproject-hg

Here I’m cloning a subversion repository to the local “someproject-hg” directory. Note the svn+https in the URL.

If you want to generate a .hgignore file based on the svn:ignore properties in the remote repository then you can issue the following command:

hg svn genignore

At this point I can interact with someproject-hg as with any other mercurial repository – I can edit files and make local commits. When I’m ready to push the changes back to the subversion server I can issue a “hg push” just as if I were pushing to a remote mercurial repository.

Likewise, if I want to retrieve new changesets from svn then I can issue a “hg pull” as normal. When you pull the changes, this will create a branch in the local repository’s history. At this point, rather than performing a “hg merge” (as you would with a normal mercurial repository) it is necessary to rebase your changes to ensure that you keep a linear history. To perform a rebase, you can issue the command:

hg rebase --svn

If you’re in a situation where you have an existing Subversion repository and you’re not yet willing to fully commit to using a DVCS, hgsubversion is a great way to let committers work with mercurial locally without needing to make any changes to your existing server.

For more information on hgsubversion, be sure to check out the documentation here and here.