Logo

Maarten Balliauw {blog}

ASP.NET, ASP.NET MVC, Windows Azure, PHP, ...

About the author

Maarten Balliauw is currently employed as .NET Technical Consultant at RealDolmen. His interests are mainly web applications developed in ASP.NET (C#) or PHP and the Windows Azure cloud platform.
More about me More about me
Send mail E-mail me


ASP.NET MVC Quickly Pro NuGet Subscribe to my RSS feed Follow me on Twitter! View Maarten Balliauw's profile on LinkedIn
Maarten Balliauw - MVP - Most Valuable Professional
Maarten Balliauw - ASPInsider

Search

Latest Twitter

    Follow me on Twitter...

    Archive

    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

    © Copyright Maarten Balliauw 2012


    Remix 2009 session - Slides and code

    As promised during the session at Remix 2009, here’s my example code and slide deck.

    Abstract: "Building a Twitter clone in 60 minutes, featuring what's new in ASP.NET MVC 2 preview 1 and focusing on some of the core ASP.NET MVC features like security and routing."

    Example code can be downloaded here: ASP.NET MVC Wisdom - ReMix.zip (8.91 mb)

    Thank you for attending!


    Categories: ASP.NET | C# | Events | General | MVC | Presentations | Testing

    Mocking - VISUG session (screencast)

    A new screencast has just been uploaded to the MSDN Belgium Chopsticks page. Don't forget to rate the video!

    Mocking - VISUG session (screencast)

    Abstract: "This session provides an introduction to unit testing using mock objects. It builds a small application using TDD (test driven development). To enable easier unit testing, all dependencies are removed from code and introduced as mock objects. Afterwards, a mocking framework by the name of Moq (mock you) is used to shorten unit tests and create a maintainable set of unit tests for the example application. "

    Slides and example code can be found in my previous blog post on this session: Mocking - VISUG session

    kick it on DotNetKicks.com


    Mocking - VISUG session

    Thursday evening, I did a session on Mocking for the VISUG (Visual Studio User Group Belgium). As promised, here is the slide deck I’ve used. The session will be available online soon, in the meantime you'll have to go with the slide deck.

    Demo code can also be downloaded: MockingDemoCode.zip (1.64 mb)

    Thank you for attending the session!

    kick it on DotNetKicks.com


    Announcing my book: ASP.NET MVC 1.0 Quickly

    ASP.NET MVC 1.0 Quickly It’s been quite a job, but there it is: Packt just announced my very first book on their site. It is titled “ASP.NET MVC 1.0 Quickly”, covering all aspects ASP.NET MVC offers in a to-the-point manner with hands-on examples. The book walks through the main concepts of the MVC framework to help existing ASP.NET developers to move on to a higher level. It includes clear instructions and lots of code examples. It takes a simple approach, thereby allowing you to work with all facets of web application development. Some keywords: Model-view-controller, ASP.NET MVC architecture and components, unit testing, mocking, AJAX using MS Ajax and jQuery, reference application and resources.

    That’s it for the marketing part: let’s do a retrospective on the writing process itself. Oh and yes, those are my glasses on the cover. Photo was taken on the beach near Bray-Dunes (France).

    When did you have the idea of writing a book?

    I'm not sure about that. I've been blogging a lot on ASP.NET MVC last year, wrote an article for .NET magazine, did some presentations, ... It occurred to me that I had a lot of material which I could bundle. Together with that, my project manager jokingly said something like: "When will you write your first book? With all that blogging." So I did start bundling stories. First of all, I overlooked the whole ASP.NET MVC technology (preview 2 at that moment) and decided there were enough topics to talk about. A draft table of contents was built quite quick, but I gave up on writing. Too much information, not enough time, ...

    A few weeks later, it must have been around the beginning of May, 2008, I did start writing a first chapter, thinking I'ld see how the writing itself would turn out, if it fit in my schedule, ... It worked out quite well, each 10-20 days gave me a new chapter. I also started looking for a publisher when I was finished with chapter 6 or so. Having reviewed some books for Packt, I contacted them with a proposal for my book.

    After having a look at the other 6 upcoming books (here and here), we decided we could go for it, focusing on a hands-on book which rapidly guides you into the wonderful world of ASP.NET MVC.

    How was your experience of writing your book?

    Looking back, it was an interesting experience. I decided to write in English, which is not my native language. That was actually quite a hard one: writing in English is no problem, but writing a good, solid and interesting piece of text is just not that easy when writing longer texts than the average blog post. Another thing is that I tortured myself writing about a product that was not even beta yet! I started writing with ASP.NET MVC preview 3, updated it all to preview 4, 5, beta, release candidate, ... Lots of changes in the ASP.NET MVC API or concepts meant lots of changes to make in chapters I already wrote. Luckily, I survived :-)

    I only contacted a publisher when I had finished 60% of my book. If you are considering writing: don't do this! Contact a publisher at a very early stage: they normally give you lots of advice upfront, which I only received after contacting them. Advice earlier along the way is always better, so that's something I would definately do different.

    Speaking of advice: when writing was done, the book entered review phase. Different people received the draft version and could provide comments and suggestions. Thanks Stefan, Troy, Vivek, Jerry, Joydip and people at Packt for your time in reviewing my draft version! Reviewer comments really made the book better and required me to do some small rewrites, elaborate more on certain topics.

    What tools did you use for writing?

    There are some tools that you really need when writing a technical book. One of them is a text editor, in my case Microsoft Word 2007. Together with that, Visual Studio 2008 and regularly updated ASP.NET MVC versions were required. Being scared of losing data, I decided to also use a source control system for sample code ánd for my Word documents. All of these files were stored in a Subversion repository located on my server, being backed up every day to different locations. Doug Mahugh laughed at me when I said I was using Subversion, but it did a great job!

    Other tools I used were Paint.NET and MwSnap, both for creating screenshots in my virtual PC running Windows Vista and Visual Studio 2008. I also used Achievo for time tracking purposes, since I was curious how much time this book writing would actually cost me.

    How much time did you spend writing?

    First of all, this is not going to be 100% accurate. I did track writing and development time during writing, but I already had a lot of material to work with. But here's an overview (numbers in hours):

    image

    That is right: writing a book consumes only a little more than 100 hours! But still, I already had lots of material. I'd say to double the number for an accurate timeframe.

    Now I hear the next question coming... Here's the answer already: Yes, I have a girlfriend. We are working on our home (planning phase is done, searching a contractor at the moment), visiting family, doing daily stuff, blogging, work, ... It al worked out to fit together, but still: there have been some busy moments on evenings and weekends. Thanks, people around me, for being patient and caring during these busy moments!

    Are you getting rich out of this?

    Of course, I can grab a couple of beers (for a couple of times), but don't think writing a book will buy you a car... I just felt that I had lots of valuable information that I had to share, and writing a book seemed like the best option to do that. Creating a "to read"-list? Make sure to add ASP.NET MVC 1.0 Quickly to it.

    kick it on DotNetKicks.com


    Book review: Software Testing with Visual Studio Team System 2008

    Software Testing with Visual Studio Team System 2008 Another book review, this time for Packt’s “Software Testing with Visual Studio Team System 2008”. The book introduces you to the main types of testing available in Visual Studio Team System 2008 for both desktop and web applications, and then walks you through deploying, running, and interpreting the results of tests.

    The book starts with an overview of why you need testing and then lists all available test types in Visual Studio 2008. It also explains the differences between a stand alone Visual Studio 2008 and a Team Foundation Server backed version. Each chapter thereafter covers one of the test types in detail: unit tests, web tests, advanced web tests, load tests, manual tests, …

    Next to these things, more information on how to deploy and run tests on a VSTS build server is provided. And when you work with a VSTS build server, chances are big reporting is enabled. These reports are also covered in detail, showing you how to interpret the data displayed.

    I’ve been working with and giving training on Visual Studio 2008 for quite a while now, including a large part on Visual Studio and testing. To be honest, I think this book really covers all aspects of testing in Visual Studio 2008, making it an ideal reference for any development team working with VSTS. Here's the official product page at Packt.

    kick it on DotNetKicks.com


    Verifying code and testing with Pex

    Pex, Automated White box testing for .NET

    Earlier this week, Katrien posted an update on the list of Belgian TechDays 2009 speakers. This post featured a summary on all sessions, of which one was titled “Pex – Automated White Box Testing for .NET”. Here’s the abstract:

    “Pex is an automated white box testing tool for .NET. Pex systematically tries to cover every reachable branch in a program by monitoring execution traces, and using a constraint solver to produce new test cases with different behavior. Pex can be applied to any existing .NET assembly without any pre-existing test suite. Pex will try to find counterexamples for all assertion statements in the code. Pex can be guided by hand-written parameterized unit tests, which are API usage scenarios with assertions. The result of the analysis is a test suite which can be persisted as unit tests in source code. The generated unit tests integrate with Visual Studio Team Test as well as other test frameworks. By construction, Pex produces small unit test suites with high code and assertion coverage, and reported failures always come with a test case that reproduces the issue. At Microsoft, this technique has proven highly effective in testing even an extremely well-tested component.”

    After reading the second sentence in this abstract, I was thinking: “SWEET! Let’s try!”. So here goes…

    Getting started

    First of all, download the academic release of Pex at http://research.microsoft.com/en-us/projects/Pex/. After installing this, Visual Studio 2008 (or 2010 if you are mr. or mrs. Cool), some context menus should be added. We will explore these later on in this post.

    What we will do next is analyzing a piece of code in a fictive library of string extension methods. The following method is intended to mimic VB6’s Left method.

    /// <summary>
    /// Return leftmost characters from string for a certain length
    /// </summary>
    /// <param name="current">Current string</param>
    /// <param name="length">Length to take</param>
    /// <returns>Leftmost characters from string</returns>
    public static string Left(this string current, int length)
    {
        if (length < 0)
        {
            throw new ArgumentOutOfRangeException("length", "Length should be >= 0");
        }

        return current.Substring(0, length);
    }

    Great coding! I even throw an ArgumentOutOfRangeException if I receive a faulty length parameter.

    Pexify this!

    Analyzing this with Pex can be done in 2 manners: by running Pex Explorations, which will open a new add-in in Visual Studio and show me some results, or by generating a unit test for this method. Since I know this is good code, unit tests are not needed. I’ll pick the first option: right-click the above method and pick “Run Pex Explorations”.

    Run Pex Explorations

    A new add-in window opens in Visual Studio, showing me the output of calling my method with 4 different parameter combinations:

    Pex Exploration Results

    Frustrated, I scream: “WHAT?!? I did write good code! Pex schmex!” According to Pex, I didn’t. And actually, it is right. Pex explored all code execution paths in my Left method, of which two paths are not returning the correct results. For example, calling Substring(0, 2) on an empty string will throw an uncaught ArgumentOutOfRangeException. Luckily, Pex is also there to help.

    When I right-click the first failing exploration, I can choose from some menu options. For example, I could assign this as a task to someone in Team Foundation Server.

    Pex Exploration Options In this case, I’ll just pick “Add precondition”. This will actually show me a window of code which might help avoiding this uncaught exception.

    Preview and Apply updates

    Nice! It actually avoids the uncaught exception and provides the user of my code with a new ArgumentException thrown at the right location and with the right reason. After doing this for both failing explorations, my code looks like this:

    /// <summary>
    /// Return leftmost characters from string for a certain length
    /// </summary>
    /// <param name="current">Current string</param>
    /// <param name="length">Length to take</param>
    /// <returns>Leftmost characters from string</returns>
    public static string Left(this string current, int length)
    {
        // <pex>
        if (current == (string)null)
            throw new ArgumentNullException("current");
        if (length < 0 || current.Length < length)
            throw new ArgumentException("length < 0 || current.Length < length");
        // </pex>

        return current.Substring(0, length);
    }

    Great! This should work for any input now, returning a clear exception message when someone does provide faulty parameters.

    Note that I could also run these explorations as a unit test. If someone introduces a new error, Pex will let me know.

    More information

    More information on Pex can be found on http://research.microsoft.com/en-us/projects/Pex/.

    kick it on DotNetKicks.com


    Integrating NUnit test results in Team Build 2008

    When using Team Foundation Server 2008 and Team Build, chances are you are developing unit tests in Microsoft’s test framework which is integrated with Visual Studio 2008. This integration offers valuable data hen a build has been finished on the build server: test run results are published in the Team Foundation Server 2008 data warehouse and can be used to create detailed metrics on how your development team is performing and what the quality of the product being developed is.

    Not all software development teams are using Microsoft’s test framework. Perhaps your team is using Team Foundation Server 2008 and creates (unit) tests using NUnit. By default, NUnit tests are not executed by the Team Build server nor are they published in the Team Foundation Server 2008 data warehouse. The following guide enables you to leverage the features Team Foundation Server 2008 has to offer regarding metrics, by customizing the build process with the necessary steps to publish test results.

    (cross-posted on RealDolmen ALM Blog)

    1. Prerequisites

    Make sure the following prerequisites are present on your Team Build server (in addition to a default build server installation):

    2. Registering NUnit framework in the global assembly cache (GAC)

    For NUnit tests to be run in a Team Build script, make sure that the NUnit framework is registered in the global assembly cache (GAC). This can be achieved by copying the file C:\Program Files\NUnit 2.4.8\bin\nunit.framework.dll to C:\Windows\Assembly.

    clip_image002

    3. Customizing a build script

    After installing all prerequisites, make sure you know all paths where these tools are installed before continuing.

    The build script for a NUnit enabled build should be modified in several locations. First of all, the MSBuild Community Tasks target file should be referenced. Next, a new build step is added in the AfterCompile hook of the build script. This build step will run the NUnit tests in the compiled DLL’s, transform them to a Microsoft Test results file (*.trx) and publish this transformed file to the Team Foundation Server 2008.

    Open the TFSBuild.proj file from source control and merge the following lines in:


    <?xml version="1.0" encoding="utf-8"?>

    <Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5"> 

        <!-- Do not edit this --> 

        <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" /> 

        <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.targets" /> 

        <ProjectExtensions> 

            <!-- ... --> 

        </ProjectExtensions> 



        <!-- At the end of file: --> 



        <ItemGroup> 

            <AdditionalReferencePath Include="$(ProgramFiles)\Nunit 2.4.7\bin\" /> 

        </ItemGroup> 



        <Target Name="AfterCompile"> 

            <!-- Create a Custom Build Step --> 

            <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Name="NUnitTestStep" Message="Running NUnit Tests"> 

                <Output TaskParameter="Id" PropertyName="NUnitStepId" /> 

            </BuildStep> 



            <!-- Get Assemblies to test --> 

            <ItemGroup> 

                <TestAssemblies Include="$(OutDir)\**\Calculator.dll"/> 

            </ItemGroup> 



            <!-- Run NUnit and check the result --> 

            <NUnit ContinueOnError="true" Assemblies="@(TestAssemblies)" OutputXmlFile="$(OutDir)nunit_results.xml" ToolPath="$(ProgramFiles)\Nunit 2.4.8\bin\"> 

                <Output TaskParameter="ExitCode" PropertyName="NUnitResult" /> 

            </NUnit> 

            <BuildStep Condition="'$(NUnitResult)'=='0'" TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(NUnitStepId)" Status="Succeeded" /> 

            <BuildStep Condition="'$(NUnitResult)'!='0'" TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(NUnitStepId)" Status="Failed" /> 



            <!-- Regardless of NUnit success/failure merge results into the build --> 

            <Exec Command="&quot;$(ProgramFiles)\nxslt-2.3-bin\nxslt2.exe&quot; &quot;$(OutDir)nunit_results.xml&quot; &quot;$(ProgramFiles)\MSBuild\NUnit\nunit transform.xslt&quot; -o &quot;$(OutDir)nunit_results.trx&quot;"/> 

            <Exec Command="&quot;$(ProgramFiles)\Microsoft Visual Studio 9.0\Common7\IDE\mstest.exe&quot; /publish:$(TeamFoundationServerUrl) /publishbuild:&quot;$(BuildNumber)&quot; /publishresultsfile:&quot;$(OutDir)nunit_results.trx&quot; /teamproject:&quot;$(TeamProject)&quot; /platform:&quot;%(ConfigurationToBuild.PlatformToBuild)&quot; /flavor:&quot;%(ConfigurationToBuild.FlavorToBuild)&quot;" IgnoreExitCode="true" /> 



            <!-- If NUnit failed it's time to error out --> 

            <Error Condition="'$(NUnitResult)'!='0'" Text="Unit Tests Failed" /> 

        </Target>

    </Project>

    4. Viewing test results

    When a build containing NUnit tests has succeeded, results of this tests are present in the build log:

    clip_image004

    When clicking the test results hyperlink, Visual Studio retrieves the result file from Team Foundation Server 2008 and displays it in the test results panel:

    clip_image006

    kick it on DotNetKicks.com


    Categories: C# | General | Testing | NUnit

    MSDN Chopsticks on ASP.NET MVC (screencasts)

    A while ago, KatrienDG asked me to do some screencasts on the ASP.NET MVC framework for the MSDN Chopsticks page. I've been working on 2 screencasts: an introductory talk to the ASP.NET MVC framework and a Test Driven Development story. Feel free to leave some comments!

    kick it on DotNetKicks.com

    Introduction to ASP.NET's MVC framework

    Abstract: "The ASP.NET MVC framework is a new approach to web development, based on the model-view-controller design pattern. Microsoft built this framework on top of ASP.NET to allow this alternative to work with existing features like membership caching, user controls... In this video, Maarten shows you some basics on the ASP.NET MVC framework like creating a new controller action and a view."

    Test Driven Development with the ASP.NET MVC framework

    Abstract: "This video explains you how to develop ASP.NET MVC web applications using 2 different approaches: regular development and test-driven development."

    Example code: MvcTodoList.zip (503.21 kb)


    Categories: ASP.NET | C# | General | MVC | Screencasts | Testing

    The devil is in the details (Visual Studio Team System test policy)

    Have you ever been in a difficult situation where a software product is overall very good, but a small detail is going wrong? At least I've been, for the past week...

    Team System allows check-in policies to be enforced prior to checking in your code. One of these policies is the unit testing policy, which allows you to enforce a specific test list to be run prior to checking in your code.

    How it is...

    Now here's the catch: what if you have a Team Project with 2 solutions in it? How can I enforce the check-in policy to run tests from solution A only when something in solution A is checked in, tests from solution B with solution B changes, ...

    How it should be...

    Creating a custom check-in policy

    To be honest, there actually are quite enough examples on creating a custom check-in policy and how to install them. So I'll keep it short: here's the source code of my solution (VS2008 only).

    kick it on DotNetKicks.com


    Categories: C# | General | Projects | Quality code | Testing

    Detailed code metrics with NDepend

    A while ago, I blogged about code performance analysis in Visual Studio 2008. Using profiling and hot path tracking, I measured code performance and was able to react to that. Last week, Patrick Smacchia contacted me asking if I wanted to test his project NDepend. He promised me NDepend would provide more insight in my applications. Let's test that!

    After downloading, extracting and starting NDepend, an almost familiar interface shows up. Unfortunately, the interface that shows up after analyzing a set of assemblies is a little bit overwhelming... Note that this overwhelming feeling fades away after 15 minutes: the interface shows the information you want in a very efficient way! Here's the analysis of a personal "wine tracking" application I wrote 2 years ago.

    Am I independent?

    Let's start with the obvious... One of the graphs NDepend generates, is a dependency map. This diagram shows all dependencies of my "WijnDatabase" project.

    Dependencies mapped

    One thing I can see from this, is that there probably is an assembly too much! WijnDatabase.Classes could be a candidate for merging into WijnDatabase, the GUI project. These dependencies are also shown in the dependency window.

    Dependencies mapped

    You can see (in the upper right corner) that 38 methods of the WijnDatabase assembly are using 5 members of WijnDatabase.Classes. Left-click this cell, and have more details on this! A diagram of boxes clearly shows my methods in a specific form calling into WijnDatabase.Classes.

    More detail on dependencies

    In my opinion, these kinds of views are really useful to see dependencies in a project without reading code! The fun part is that you can widen this view and have a full dependency overview of all members of all assemblies in the project. Cool! This makes it possible to check if I should be refactoring into something more abstract (or less abstract). Which is also analysed in the next diagram:

    Is my application in the zone of pain?

    What you can see here is the following:

    • The zone of pain contains assemblies which are not very extensible (no interfaces, no abstract classes, nor virtual methods, stuff like that). Also, these assemblies tend to have lots of dependent assemblies.
    • The zone of uselessness is occupied by very abstract assemblies which have almost no dependent assemblies.

    Most of my assemblies don't seem to be very abstract, dependencies are OK (the domain objects are widely used so more in the zone of pain). Conclusion: I should be doing some refactoring to make assemblies more abstract (or replacable, if you prefer it that way).

    CQL - Code Query Language

    Next to all these graphs and diagrams, there's another powerful utility: CQL, or Code Query Language. It's sort of a "SQL to code" thing. Let's find out some things about my application...

     

    Methods poorly commented

    It's always fun to check if there are enough comments in your code. Some developers tend to comment more than writing code, others don't write any comments at all. Here's a (standard) CQL query:

    // <Name>Methods poorly commented</Name>
    WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE PercentageComment < 20 AND NbLinesOfCode > 10  ORDER BY PercentageComment ASC
    // METHODS WHERE %Comment < 20 and that have at least 10 lines of code should be more commented.
    // See the definition of the PercentageComment metric here http://www.ndepend.com/Metrics.aspx#PercentageComment

    This query searches the top 10 methods containing more than 10 lines of code where the percentage of comments is less than 20%.

    CQL result 

    Good news! I did quite good at commenting! The result of this query shows only Visual Studio generated code (the InitializeComponent() sort of methods), and some other, smaller methods I wrote myself. Less than 20% of comments in a method consisting of only 11 lines of code (btnVoegItemToe_Click in the image) is not bad!

    Quick summary of methods to refactor

    Another cool CQL query is the "quick summary of methods to refactor". Only one method shows up, but I should probably refactor it. Quiz: why?

    CQL result

    Answer: there are 395 IL instructions in this method (and if I drill down, 57 lines of code). I said "probably", because it might be OK after all. But if I drill down, I'm seeing some more information that is probably worrying: cyclomatic complexity is high, there are many variables used, ... Refactoring is indeed the answer for this method!

    Methods that use boxing/unboxing

    Are you familiar with the concept of boxing/unboxing? If not, check this article. One of the CQL queries in NDepend is actually finding all methods using boxing and unboxing. Seems like my data access layer is boxing a lot! Perhaps some refactoring could be needed in here too.

    CQL result

    Conclusion

    Over the past hour, I've been analysing only a small tip of information from my project. But there's LOTS more information gathered by NDepend! Too much information, you think? Not sure if a specific metric should be fitted on your application? There's good documentation on all metrics as well as short, to-the-point video demos.

    In my opinion, each development team should be gathering some metrics from NDepend with every build and do a more detailed analysis once in a while. This detailed analysis will give you a greater insight on how your assemblies are linked together and offer a great review of how you can improve your software design. Now grab that trial copy!

    kick it on DotNetKicks.com