Cogimator.Net

SimpleValidation.NET for ASP.NET MVC released

Mathieu — Mon, 25 Aug 2008 21:28:22 +0100

Still in alpha, and still a bit proof of concept, I released today a new version that supports ASP.NET MVC (Preview 4). Client side validation is handled by jquery.validation (http://docs.jquery.com/Plugins/Validation).

Currently, only required and email validators are implemented. Type validation is done server side. I will continue to add features during the week. Now, let's validate some users!

Still simple to use, all you have to do is :

Download the project on codeplex : http://www.codeplex.com/SimpleValidation

Create your entity (nothing new here!)

public class User
{
    private string name;
    private int age;
    private string email;
    private string password;
    private decimal size;

    [Required("Name is required")]
    public string Name
    {
        get { return this.name; }
        set { this.name = value; }
    }

    [Required("Age is required")]
    [Range(0, 99, "Age must be in range {0} {1}")]
    [ValidateType("Age format is not valid")]
    public int Age
    {
        get { return this.age; }
        set { this.age = value; }
    }

    [ValidateType("Size format is not valid")]
    public decimal Size
    {
        get { return this.size; }
        set { this.size = value; }
    }

    [Email("Email is invalid")]
    [Confirm("Please confirm your email")]
    [Required("Email is required")]
    public string Email
    {
        get { return this.email; }
        set { this.email = value; }
    }

    [Confirm("Please confirm your password")]
    [Required("Password is required")]
    public string Password
    {
        get { return this.password; }
        set { this.password = value; }
    }
}

This one is self explanatory

Create your view

<%=Html.CreateValidators<Samples.Entities.User>("signupForm")%>

<%using( Html.Form("User", "New", FormMethod.Post, new Dictionary<string, object>() { { "id", "signupForm"} } ) ) { %>
    <div class="inputform">
        <fieldset>
            <legend>
                User
            </legend>
            <label>Name:</label>
            <div class="droite">
                <%= Html.TextBox("Name", ViewData["Name"] as string) %>
                <%= Html.ValidationErrors("Name") %>
            </div>
            
            <label>Password:</label>
            <div class="droite">
                <%= Html.TextBox("Password")%>
                <%= Html.ValidationErrors("Password")%>
            </div>
            
            <label>Confirm Password:</label>
            <div class="droite">
                <%= Html.TextBox("PasswordConfirm")%>
                <%= Html.ValidationErrors("PasswordConfirm")%>
            </div>

            <label>Age:</label>
            <div class="droite">
                <%= Html.TextBox("Age", ViewData["Age"] as string)%>
                <%= Html.ValidationErrors("Age")%>
            </div>
            
            <label>Size:</label>
            <div class="droite">
                <%= Html.TextBox("Size", ViewData["Size"] as string)%>
                <%= Html.ValidationErrors("Size")%>
            </div>

            <label>Email:</label>
            <div class="droite">
                <%= Html.TextBox("Email", ViewData["Email"] as string)%>
                <%= Html.ValidationErrors("Email")%>
            </div>

            <label>Confirm Email:</label>
            <div class="droite">
                <%= Html.TextBox("EmailConfirm", ViewData["EmailConfirm"] as string)%>
                <%= Html.ValidationErrors("EmailConfirm")%>
            </div>
            
            <div class="droite boutons">
                <input type="submit" value="Register" />
            </div>
        </fieldset>

    </div>
<%} %>

Don't forget to add a reference to jquery (http://jquery.com/) and jquery.validation (http://docs.jquery.com/Plugins/Validation)

Create your controller

public class UserController : Controller
{
    public ActionResult Index()
    {
        return View("New");
    }

    public ActionResult New()
    {
        User u = new User();

        if (!MvcValidationHelper.UpdateFrom(u, Request.Form, ViewData))
        {
            return View();
        }

        return View("UserCreated", u);
    }
}

And there you go !

First release of NHibernate Entity Generator

Mathieu — Thu, 31 Jul 2008 22:42:00 +0100

Today I released a small code generator : from hbm files it can generate your entities and DAL, grab it while it's hot : http://www.codeplex.com/EntityGenerator :)

NHibernate error : identifier type mismatch

Mathieu — Tue, 15 Jul 2008 20:34:00 +0100

If your entity has an id type of long, and you try to get it with ISession.Get<T>( 123 ), it will pass 123 as an int, and the following exception is thrown :

System.ArgumentException : identifier type mismatch
Parameter name : id

You can use ISession.Get<T>( (long)123 ), but it's not very clean. And it has caused some hair pulling to me :)

An alternative is to use :

id = Convert.ChangeType( id, typeof(T).GetProperty("Id").PropertyType);

ISession.Get<T>( id );

but still not very clean...

First release of SimpleValidation.NET, an ASP.NET validation framework

Mathieu — Thu, 03 Jul 2008 22:08:00 +0100

SimpleValidation.NET is a simple validation (!) framework, designed to work with ASP.NET and entities (or domain objects, or whatever you like :)). Its primary goal was simplicity of usage, and as i'm a big fan of "Show, dont tell" :

First, you have to create your entity. It can be an NHibernate mapped entity, for example. After that, you just tag it's properties :

public class UserEntity
{
    private string name;
    private int age;
    private string email;
 
    [Required("Name is required")]
    public string Name
    {
        get { return this.name; }
        set { this.name = value; }
    }
            
    [Required("Age is required")]
    [Range(0, 99, "Age must be in range {0} {1}")]
    public int Age
    {
        get { return this.age; }
        set { this.age = value; }
    }
 
    [Email("Email is invalid")]
    [Confirm("Please confirm your email")]
    [Required("Email is required")]
    public string Email
    {
        get { return this.email; }
        set { this.email = value; }
    }
}

After that, add a simple form to your page :

<div runat="server" id="inputForm" class="inputform">
<label>Name:</label>
<asp:TextBox runat="server" ID="Name" />
<label>Age:</label>
<asp:TextBox runat="server" ID="Age" />
<label>Email:</label>
<asp:TextBox runat="server" ID="Email" />
<label>Confirm Email:</label>
<asp:TextBox runat="server" ID="EmailConfirm" />
<asp:Button runat="server" ID="btn" Text="Test" />
</div>

And the WebValidationHelper control :

<SimpleValidation:WebValidationHelper ID="WebValidationHelper1" runat="server" 
EntityType="Samples.Entities.UserEntity, Samples.Entities" 
ValidatorDisplay="Dynamic"
ParentControl="inputForm" />

And here we go : corresponding validators are added automatically !

How is it working ?

Very simply : you have to name your inputs with the same name as your entity's properties (convention over configuration here). Then, validators are added after the input control by default. You can also do the validation manually, or specify placeholders (they are located by prefix, like "ValidatorsForName"). For more details, you can look at the samples included in source code.

The project is hosted on codeplex here : http://www.codeplex.com/SimpleValidation/

Continuous Integration Part 4 : Unit Testing

Mathieu — Sat, 14 Jun 2008 19:09:00 +0100

This post is quite simplistic about unit testing, but I hope it will make you try ! Simply put, an unit test is a piece of code that will test another piece of code. The "unit" part means that we will test an "unit" of our code, like a class and its methods. Unit tests are runned with NUnit (http://www.nunit.org).

Lets take a "simple" method :

public class StringUtil 
{ 
    public static string GetLength( string input ) 
    { 
        return input.Length; 
    }
}

The test will look like this (add a reference to nunit.framework.dll) :

[TestFixture] 
public class StringUtilTest 
{ 
    [Test] 
    public void GetLenghTest() 
    { 
        Assert.That( StringUtil.GetLength( "ab" ) == 2 ); 
        Assert.That( StringUtil.GetLength( "abc" ) == 3 ); 
        Assert.That( StringUtil.GetLength( "abcd" ) == 4 ); 
    } 
}

This test checks the internals of our method : given known input parameters ("abc"), we expect a specific output (3). Now, our method looks correct, and we have 100% coverage for it. But 100% coverage doesn't mean 0% bugs. Unit testing cannot test non existing code, like missing error checks, for example.

Now, an user submits a bug : "when I pass null to "GetLength", it fails with a NullReferenceException!". We now have two options : we return 0 if null is passed, or we throw an ArgumentNullException. We'll implement option 2. But before updating or GetLength method, we should add another test :

[TestFixture] 
public class StringUtilTest 
{ 
    [Test] 
    public void GetLenghtTest() 
    { 
        Assert.That( StringUtil.GetLength( "ab" ) == 2 ); 
        Assert.That( StringUtil.GetLength( "abc" ) == 3 ); 
        Assert.That( StringUtil.GetLength( "abcd" ) == 4 ); 
    } 

    [Test] 
    [ExpectedException(typeof(ArgumentNullException))] 
    public void GetLenghtArgNulTest 
    { 
        StringUtil.GetLength( null ); 
    } 
}

If we launch tests, "GetLengthArgNulTest" will fail, as we're expecting an ArgumentNullException, and we get a NullReferenceException. We leverage unit tests to reproduce the bug, before correcting it. It ensures that when the bug is corrected, it stays corrected. And we improve our state coverage.

public class StringUtil 
{ 
    public static string GetLength( string input ) 
    { 
        if( input == null ) throw new ArgumentNullException( "Please dont feed me with null!"); 
        return input.Length; 
    } 
}

Everything is now green in NUnit!

Now, why are we writing this bunch of code, comment and maintain it ? For fiability, and future maintenance of our application : a modification in a portion of test covered code is much safer than the same modification in uncovered code.

In a multi layered application, you can test layers independantly. You don't need to go to all UI features to test your access layer. Finally, testable code is more modular, as modularity improves testability.

Continuous Integration Part 3 : Integrating Microsoft Source Analyzer Tool to our build process

Mathieu — Thu, 05 Jun 2008 23:33:00 +0100

Two weeks ago, Microsoft released "Microsoft Source Analyzer Tool for C#" (I'll call it MSAT). This tool, also known as "StyleCop", enforces coding style rules against your source code. It is really useful when working in teams : everyone has to follow the same coding style, making source understanding easier for everyone.

Installing

MSAT can be downloaded here : http://code.msdn.microsoft.com/sourceanalysis/Release/ProjectReleases.aspx?ReleaseId=1047. Installation is straightforward, just be sure to have the MSBuild checkbox checked, or there won't be any MSBuild integration available.

Integrating in your projects

When you have installed MSAT, a new entry appears in the "Tools" menu inside Visual Studio : "Run Source Analysis". You can now launch source analysis inside Visual Studio, the results will be inside "Source Analysis" tab. Double-click a message, and you will go to the affected line. Nothing unusual!

You can also directly include source analysis in the build process. And that's pretty cool : every time a developper build the project, the analysis is run, and results displayed inside "Warning" section of the "Errors" tab. Now, there are two options :

- MSAT is installed on every developper's pc

For every project you wish to enable source analysis, open the .csproj file using a text editor, and edit it this way :

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
[...] 
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" /> 
<Import Project="$(ProgramFiles)\MSBuild\Microsoft\SourceAnalysis\v4.2\Microsoft.SourceAnalysis.targets" /> 
[...] 
</Project>

- MSAT isn't installed on every developper's PC

Following my project tree post, you can add MSAT folder inside the "External" folder of your solution : create a "SourceAnalysis" folder, and copy everything inside "C:\Program Files\Microsoft Source Analysis Tool for C#" into it. For every project you wish to enable source analysis, open the .csproj file using a text editor, and edit it this way :

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
[...] 
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" /> 
<Import Project="..\..\External\SourceAnalysis\Microsoft.SourceAnalysis.targets" /> 
[...] 
</Project>

Finally, add this directory ("SourceAnalysis") to the repository : every developper will get free Source Analysis on their next update !

Note : when you load your projects after modifying the .csproj file, a warning will appear : choose to load the project normally.

Et voilà! Source analysis is now integrated in our build process!

Continuous Integration Part 2 : Solution tree

Mathieu — Thu, 05 Jun 2008 20:46:05 +0100

Before going further, it can be useful to have a look at a "standard" solution tree, that I will be using for upcoming posts :

Apps : applications : Winforms, Console, WebForms, everything that is executable
Libs : class libraries, module, components : everything that is not executable.
References : every external libraries used in your solution (NHibernate, Castle Project, etc)(not visible in Visual Studio, only in the "physical" directory)
Scripts : build scripts, deployments scripts
Tests : unit tests

Important : if you create solution folders inside Visual Studion you have to physical" folder, beware when you add projects to them. By default, Visual Studio adds them to the physical solution root dir. It's the same for solution elements, that are created inside solution root. It's safer to create solution elements manually, inside the desired folder, then add them to the solution by "Add existing element".

This solution tree is only for demonstration purpose. It's probably not the best, but it's not the worst either. It's always nice to have consistency between projects, and it simplifies greatly continuous integration process.

Regarding external libraries, I chose to link them on a "by solution" basis : it's simplier to make an update : you don't worry about breaking something, you can update your libraries solution by solution and test accordingly.

Continuous Integration Part 1 : Source Control made easy

Mathieu — Thu, 05 Jun 2008 20:29:00 +0100

This time, we'll see how to install and use Subversion. You will have to download VisualSVN Server (http://www.visualsvn.com/server/) and TortoiseSVN (http://tortoisesvn.tigris.org/). You can also download AnkhSVN (http://ankhsvn.open.collab.net/) if you want Visual Studio integration (for Visual Studio 2008, take version 1.0.3 or later).

VisualSVN Server, TortoiseSVN and AnkhSVN installation are straightforward. When VisualSVN Server is installed on our server, and TortoiseSVN on our client(s), we can begin.

During VisualSVN Server installation, you just have to remember the path labeled "Repositories location" for backup purposes.

Server side

First, you need to create a place where source code will be stored : a repository. Every modification of the code in the repository (commit) will increment its version number. Repositories are created in the repositories path specified during VisualSVN Server installation (c:\repositories by default). This is the only directory you need to backup. If you restore this directory on another server, install VisualSVN Server, everything (repositories, source code, users and groups) is back to normal!

Now you can launch "VisualSVN Server Manager", and "Create a repository". You can name your repository after your project's name. Do not forget to leave "Create default structure" checked : it will create 3 directories, at your repository's root :

trunk : development version of your source code
tags : specific (released) revisions of source code
branches : development duplications of trunk, for adding new features that don't belong to the trunk at this point of time.

You can have a look at this post from Bill Simser who explains very well those concepts.

Now we have a repository, let's add some access control. You can create your developpers by clicking on "Create new user", and create your groups with "Create new group". You can associate users into groups. Finally, to define access rules, right click on your repository in the treeview, and choose "Security".

Before going client side, remember your repository's url, like http://server:8080/svn/RepositoryName.

Client side

Now that we have a repository, we need to create a local copy of it. Every modification made on the local copy is made on the repository, after you "commit" it. Every modification on the repository is made on local copy by "updating" it.

You can create a folder on your development machine (like d:\ContinuousIntegration), right click on it and choose "SVN Checkout". Now enter your repository's url, appended by "trunk" : http://server:8080/svn/RepositoryName/trunk. Remember : trunk is your development branch.

Your local copy is ready. If you add files and folders inside, you just have to right-click, choose "Commit" and it's done (after a dialog), it's on the repository, with version tracking!

You can simplify some things, like never commit bin, obj, *.suo and *.user. You just have to right-click, TortoiseSVN -> Settings. Inside General, Subversion, fill "bin obj *.suo *.user" inside "Global ignore patterns". There is no use storing compilation products inside the repository : everything you need to make it is already there !

How to properly commit

1. Bob (our developper) updates his local copy, to get the latest version of the code
2. Bob modifies the code
     2.1 If code doesn't compile, back to 2.
     2.2 If code compiles, go to 3.
3. Bob updates his local copy, to get modification that can have been made on the repository since 1.
     3.1 If code doesn't compile, back to 2.
     3.2 If code compiles, go to 4.
4. Bob commits his modifications.

Point 3 is very important : it ensures that Bob's modifications don't conflict with code in the repository. Which leads us to the most important point : the code in the repository must compile. Everytime. If someone updates his local copy with code that doesn't compile, he will be losing valuable time : who commited the code, why doesn't it compile, how to correct...

Continuous integration Introduction

Mathieu — Tue, 03 Jun 2008 20:49:00 +0100

Currently translating from my french blog http://www.cogimator.net, a small group of posts about continuous integration in .net.

Those posts will cover :

source control server : Visual SVN Server
solution tree
Microsoft Source Analysis Tool for c#
unit testing with NUnit
build automation with NAnt
mocking introduction
continuous integration server setup with CruiseControl
managing developper specific configuration files
automating packaging and deployment