Paulo Morgado

Web Client Software Factory 2.0 shipped

About the Deliverable

The Web Client Software Factory (WCSF) provides a set of guidance for architects and developers building enterprise Web applications. The factory includes samples, reusable code and a guidance package which automates key development tasks from within Visual Studio.

Using the Web Client Software Factory assets, developers can create Composite Web applications composed of independently developed and deployed modules. These modules are dynamically brought together at runtime into a common shell. Additionally the factory includes support for ASP.NET AJAX thus providing users with a richer and more responsive user experience.

New In This Release

The February 2008 release of the Web Client Software Factory has the following improvements to the June 2007 release.

• Full support for Visual Studio 2008 and .NET Framework 3.5
• Added ASP.NET AJAX extenders for Context Sensitive Autocomplete, AJAX Validation, and Real Time Search that can be used in existing ASP.NET sites and ASP.NET sites built using the Composite Web Application Block.
• Added UI Composition capability through extending our dependency injection mechanism to support Pages, User Controls and Master Pages.
• Added Dependency Injection on ASMX Web Services and JSON services.
• Added a new set of Quickstarts and How-To topics on MVP, Modularity and the new AJAX extenders
• Added a new Order Entry Reference application that demonstrates all of the new functionality.

In addition, this release of WCSF has the following community issues and fixes:

• 42 Workitems closed including the top-voted items on CodePlex
• Add ASP.NET AJAX Support (97 votes)
• Web Client Software Factory Support for Enterprise Library 3.1 (62 votes)
• Services through configuration (32 votes)
• Support for using the Validation Application Block (16 votes)
• Recipe support for Visual Basic .NET (20 votes)
• Added Presenter support for Master Pages (11 votes)

FormsAuthentication And Query String Parameteres

Today I ran into this strange"feature" of ASP.NET:

When redirecting to the login page, the query string parameters are encoded with the requested URL into the ReturnUrl query string parameter of the request to the login page, but are also in the query string of the request to the login page.

Here is an example:

When requesting:

http://localhost:5014/FormsAuthentication/default.aspx?test=true

we are redirected to:

http://localhost:5014/FormsAuthentication/login.aspx?ReturnUrl=%2fFormsAuthentication%2fdefault.aspx%3ftest%3dtrue&test=true

See the test parameter?

As far as I know, this is not documented or overridable.

Techdays Portugal 2008 - For A World 2.0

Microsoft Portugal will be hosting Techdays 2008 from Mars 12^nd to 14^th, right after the Portuguese launch of Microsoft Visual Studio 2008, Microsoft SQL Server 2008 and Microsoft Windows Server 2008 on Mars 11^th.

This is the biggest and greatest tech event in Portugal and there will be lots of national and international speakers and contests.

I'll be there. Come visit us.

Typemock Insulator Is Typemock Isolator

Yesterday I made a mistake with the name of the next version of TypeMock. The real name is TypeMock Isolator. Whatever the name is, you should try it out.

TypeMock Insulator 4.2 Beta Publicly Available

TypeMock (now called) Insulator 4.2 Beta is publicly available. Check out the release notes.

One of my favorite new features is the improved mock chaining.

Take this class to be tested:

public class TestedClass1
{
    public IDictionary<string, object> Dictionary
    {
        get { throw new NotImplementedException(); }
    }

    public object Method(bool cond)
    {
        if (cond)
        {
            return Dictionary["true"];
        }
        else
        {
            return Dictionary["false"];
        }
    }
}

The following test:

[TestMethod]
[VerifyMocks]
public void TestMethod1()
{
    object trueObject = new object();
    object falseObject = new object();

    TestedClass1 target = RecorderManager.CreateMockedObject<TestedClass1>();

    using (RecordExpectations recorder = RecorderManager.StartRecording())
    {
        recorder.DefaultBehavior.CheckArguments();

        recorder.ExpectAndReturn(target.Dictionary["true"], trueObject);
        recorder.FailWhenCalled(target.Dictionary["false"]);
    }

    object value = target.Method(true);
    Assert.AreEqual(trueObject, value);
}

Would simply fail with:

Test method TestProject1.UnitTest1.TestMethod1 threw exception:  TypeMock.VerifyException: 
TypeMock Verification: Method TestProject1.TestedClass1.get_Dictionary() has 1 more expected calls
.

Now, it just passes.

Visual Studio cues are nice too.

POUT - That's The Way I Like It

POUT - Plain Old Unit Testing

Read all about it here.

TDD Proven Effective! Or is it? - by Jacob Proffitt

Jacob Proffitt has some comments about the the paper on the effectiveness of test-first approach to programming.

Here are a few excerpts:

If you're like me, you understand the problem better after implementing it and can thus create more relevant tests after the fact than before. I know better where the important edge-cases are and how to expose them and that could mean that my tests are more robust.

Anyway, without question, testing first leads to having more tests per functional unit. The question is if this is valuable.

WCSF geekSpeak: Download Available On Channel 9