Paulo Morgado : ASP.NET

PowerShell For The .NET Developer

Paulo Morgado — Fri, 18 Sep 2009 00:03:12 GMT

Some time ago I needed to have the validationKey of the machineKey element of an ASP.NET application changed and found out that ASP.NET doesn’t provide a command-line tool (or any other) to do this.

Looking around I found several applications and code samples to do it, but to have a system administrator do this I needed to test and document the application and it was to much work for such task.

I’ve always been a supporter of the idea of PowerShell but I never used it my self. Just because I almost always have Visual Studio open and writing a simple console application is quicker and easier than learning PowerShell.

This time I decide that I would do a PowerShell script instead.

In C# I would have done something like this:

class Program
{
    private static string GenerateKey()
    {
        var buff = new byte[64];
        (new System.Security.Cryptography.RNGCryptoServiceProvider()).GetBytes(buff);
        var sb = new System.Text.StringBuilder();
        foreach (var b in buff)
        {
            sb.AppendFormat("{0:X2}", b);
        }
        return sb.ToString();
    }

    private static void Main(string[] args)
    {
        var path = args[0];
        var config = System.Web.Configuration.WebConfigurationManager.OpenMachineConfiguration(path);
        var systemWeb = config.GetSectionGroup("system.web") as System.Web.Configuration.SystemWebSectionGroup;
        var machineKey = systemWeb.MachineKey;
        machineKey.ValidationKey = GenerateKey();
        config.Save(System.Configuration.ConfigurationSaveMode.Modified);
    }
}

How would it be in PowerShell? As simple as this:

function GenerateKey
{
    [System.Byte[]]$buff = 0..63
    (new-object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($buff)
    $sb = new-object System.Text.StringBuilder(128)
    for($i = 0; ($i -lt $buff.Length); $i++)
    {
        $sb = $sb.AppendFormat("{0:X2}", $buff[$i])
    }
    return $sb.ToString()
}

[System.Reflection.Assembly]::LoadWithPartialName("System.Web")
$config = [System.Web.Configuration.WebConfigurationManager]::OpenWebConfiguration("<path>")
$systemWeb = $config.GetSectionGroup("system.web");
$machineKey = $systemWeb.MachineKey
$machineKey.ValidationKey=GenerateKey
$config.save("Modified")

Wonder how I got from no knowledge of PowerShell to this? Simple. Something that every real .NET developer has and loves: .NET Reflector (with a PowerShell add-in, of course).

ReMIX 09 Is Coming To Lisbon, Portugal

Paulo Morgado — Wed, 09 Sep 2009 18:50:28 GMT

For the first time, ReMIX is coming to Portugal.

The event will have a keynote and 3 tracks (Web Developer, UX and Architect) with 4 sessions each by the best speakers in each field.

Don’t miss it! Register now!

Typemock Is Launching The ASP.NET Bundle – Get Free Licenses

Paulo Morgado — Mon, 18 May 2009 22:57:00 GMT

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch they are giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator and Ivonna, the ASP.NET Isolator add-on, for a discounted price.

ASP.NET Bundle launch giveaway:
For the ASP.NET Bundle launch Typemock are giving away free licenses to bloggers and their readers.

How do I get the free license?

Are you a blogger, webmaster, or internet columnist? Get your free license by helping Typemock launch their new ASP.NET Bundle, the ultimate ASP.NET unit testing solution.

Post the text below on your blog (as is, with links) and tell them about it . If you are in the first 60 to mail us after posting, your license will be on its way!

If you have an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.

8 bloggers will also get an additional 2 licenses (each) to give away / raffle to their readers or friends.

A few simple requirements:

You must own a website, blog space or internet column, older than 2 months, or get permission from the owner of such a site.
Your post must include the text below (including the links) between *Begin* and *End*.

*Begin*

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.

Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

*End*

Once you post this in your site, just drop them a line at asp@typemock.com with your name and the post URL to get your free license.

Hurry up – this offer is limited to the first 60 bloggers, or to ASP.NET dedicated bloggers who will post this in the first week.

Make sure to follow their Blog, Site or Twitter for updates on this event.

ASP.NET Futures: Control ClientID Generation

Paulo Morgado — Wed, 18 Mar 2009 01:44:50 GMT

ASP.NET is expected to have some improvements on the generation of client IDs.

Although this is a major improvement, it comes short by not allowing the generation of shorter client IDs for server controls.

My good friend Nuno Gomes has done some work on generating shorter client IDs for controls (*).

Jeff has taken it one step further with his How to shorten ASP.NET automatically generated control IDs article on CodeProject.

If you want to see a running example, check out http://www.biocompare.com/.

(*)

How To Issue Server Callbacks

Paulo Morgado — Mon, 15 Dec 2008 01:03:48 GMT

Callbacks were introduced in ASP.NET 2.0 and is a simple mechanism for calling page or control functionality without page rendering and without the user noticing a post back.

For a page or control to handle callbacks, all it needs is to implement the ICallbackEventHandler Interface.

When the client calls back to de page or control, the initial state of the controls is posted along with the control being called upon in the __CALLBACKID field and the callback parameter in the __CALLBACKPARAM field.

It’s quite a simple procedure.

But what if you want to issue a callback server side?

In order for a request to be identified as a callback (IsCallback), the request must be a postback (IsPostback) and the before mentioned fields must be in the post data of the request. On the other hand, for a request to be considered a postback, the level of server calls (Transfer or Execute) must be 0 (meaning that the current request hasn’t made any Transfer or Execute calls) or the type of the page is the same of the Handler for the current request and the HTTP method is POST.

Changing the HTTP method is (as far as I know) impossible. So, if the request is not already a POST, there’s no way to issue a callback.

Setting the post data is easier. All it’s needed is to override the page’s DeterminePostBackMode method (or in a page adapter) and return the post data previously saved in a context item. Something like this:

protected override NameValueCollection DeterminePostBackMode()
{
    NameValueCollection postBackMode = Context.Items["callbackPostData"] as NameValueCollection;

    return (postBackMode != null) ? postBackMode : base.DeterminePostBackMode();
}

And issue a callback is something like this:

IHttpHandler handler = this.Context.Handler;
try
{
    NameValueCollection postData = new NameValueCollection();
    postData.Add("__CALLBACKID", sender);
    postData.Add("__CALLBACKPARAM", this.argument.Text);

    Context.Items["callbackPostData"] = postData;

    Page calledPage = (Page)PageParser.GetCompiledPageInstance("~/Callback1.aspx", this.Server.MapPath("~/Callback1.aspx"), this.Context);

    this.Context.Handler = calledPage;

    StringWriter writer = new StringWriter();

    Server.Execute(calledPage, writer, false);

    this.response.Text = writer.ToString();
}
finally
{
    this.Context.Handler = handler;
}

You can find an implementation of a caller and a called page here.

Serialized In-Process ASP.NET Session State Store

Paulo Morgado — Mon, 04 Aug 2008 01:09:00 GMT

ASP.NET provides out of the box three session state stores:

Provider	Description
InProc	Session state is stored in the ASP.NET cache.
SQLServer	Session state is stored out-of-process in an SQL Server database.
StateServer	Session state is stored out-of-process in an ASP.NET state service.

Because with SQLServer and StateServer providers the state must cross the AppDomain boundary it needs to be serialized when stored and deserialized when loaded. Because the state needs to be loaded and stored on each request, it is only available from the PostAcquireRequestState to the ReleaseRequestState events. And, because of serialization and deserialization, all objects stored must be serializable any reference held to one of the session state items won’t be to the same item after being deserialized.

On the other hand, with the InProc provider, the state will never be serialized or deserialized, which means that objects don’t need to be serializable and any reference to an item in the state is always a reference to the item in the state even before the PostAcquireRequestState event and after the ReleaseRequestState event.

In practice, developers use the InProc provider and applications are deployed to production using the SQLServer provider. This usually leads to application errors, like storing non serializable objects in the state, that are only uncovered in production. That’s why I’ve written a serializable in-process session state store. You can find the sources here.

IIS/ASP.NET Cookieless Support Not Working As Expected

Paulo Morgado — Fri, 01 Aug 2008 00:23:02 GMT

In one of the environments I work, cookies cannot be used because the pages run inside web browser controls running on a client application and cookies end up being shared by all browsers.

Fortunately, ASP.NET allows us to persist some cookies as part of the URL.

To persist the session state identifier cookie in the URL we just need to add the following configuration:

<configuration>
  <system.web>
    <sessionState cookieless="UseUri" />
  </system.web>
</configuration>

and you’ll get URLs like this:

http://localhost/Cookieless/(S(jcmwek3ja0lvdpbwoacpjirv))/default.aspx

The way IIS and ASP.NET do this is by IIS removing the section between parenthesis after the virtual directory path and adding the AspFilterSessionId HTTP header to the request. Than, ASP.NET picks it up and extracts the cookie.

I wrote this simple page to demonstrate this working:

<%@ Page Language="C#" AutoEventWireup="true" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <table>
            <tr>
                <td>Raw URL</td>
                <td><%= Request.RawUrl %></td>
            </tr>
            <tr>
                <td>Cookiless Cookies<br />AspFilterSessionId Request HTTP Header</td>
                <td><%= Request.Headers["AspFilterSessionId"] %></td>
            </tr>
            <tr>
                <td>Session ID</td>
                <td><%= Session.SessionID %></td>
            </tr>
        </table>
    </div>
    </form>
</body>
</html>

For the above URL, we'll get a page like this:

Raw URL	/Cookieless/default.aspx
Cookiless Cookies AspFilterSessionId Request HTTP Header	S(jcmwek3ja0lvdpbwoacpjirv)
Session ID	jcmwek3ja0lvdpbwoacpjirv

IIS strips these cookies even for serving static content like cascading stylesheets.

You can test this by creating a default theme. You can do this by adding a Default folder under the App_Themes folder and adding a Styles.css file to it:

body
{
    background-color: Yellow;
}
table, tr, td
{
    border: thin solid black;
}

and setting the theme as default using the following configuration:

<configuration>
  <system.web>
    <sessionState cookieless="UseUri" />
    <pages theme="Default"/>
  </system.web>
</configuration>

And you'll get a "pretier" page:

Raw URL	/Cookieless/default.aspx
Cookiless Cookies AspFilterSessionId Request HTTP Header	S(jcmwek3ja0lvdpbwoacpjirv)
Session ID	jcmwek3ja0lvdpbwoacpjirv

If you have special needs for your session state identifiers, you can implement your own session identifier manager.

But if you want to use cookieless cookies, you only have one way to do it: extend the SessionIDManager class:

public class SessionIdManager : System.Web.SessionState.SessionIDManager
{
    public override string CreateSessionID(System.Web.HttpContext context)
    {
        string id = System.Guid.NewGuid().ToString("B");

        return id;
    }

    public override bool Validate(string id)
    {
        try
        {
            new System.Guid(id);
            return true;
        }
        catch
        {
            return false;
        }
    }
}

and configure the session state module to use it:

<configuration>
  <system.web>
    <sessionState cookieless="UseUri" sessionIDManagerType="SessionIdManager" />
    <pages theme="Default"/>
  </system.web>
</configuration>

And we'll end up with this nice page:

http://localhost/Cookieless/(S(%7b0861e55a-e29b-4b6f-825b-1e1d4c57f095%7d))/default.aspx

Raw URL	/Cookieless/(S({0861e55a-e29b-4b6f-825b-1e1d4c57f095}))/default.aspx
Cookiless Cookies AspFilterSessionId Request HTTP Header
Session ID	{0861e55a-e29b-4b6f-825b-1e1d4c57f095}

OOPS! What happened here?

Looks like IIS was unable to transfer the cookies to the appropriate HTTP header but ASP.NET was able to find the requested resource. On the other hand, IIS couldn’t find the http://localhost/Cookieless/(S(%7b0861e55a-e29b-4b6f-825b-1e1d4c57f095%7d))App_Themes/Default/Styles.css.

This happens in these environments:

Operating System	IIS	ASP.NET
Windows XP Pro SP3	5.1	2.0 SP1, 3.5
Windows Server 2003 R2	6	2.0 SP1, 3.5
Windows Server 2008	7	2.0 SP1, 3.5

Fortunately, in IIS 7 you can have HTTP modules in integrated pipeline mode that are called for every resource requested to IIS.

Your module doesn’t even need to do nothing. It just needs to exist:

public class Module : System.Web.IHttpModule
{
    public void Dispose()
    {
    }

    public void Init(System.Web.HttpApplication context)
    {
    }
}

and be added to the configuration:

<configuration>
  <system.web>
    <sessionState cookieless="UseUri" sessionIDManagerType="SessionIdManager" />
    <pages theme="Default"/>
  </system.web>
  <system.webServer>
    <modules>
      <add name="Module" preCondition="integratedMode" type="Module" />
    </modules>
  </system.webServer>
</configuration>

And our “pretty” page is back:

Raw URL	/Cookieless/default.aspx
Cookiless Cookies AspFilterSessionId Request HTTP Header	S({0861e55a-e29b-4b6f-825b-1e1d4c57f095})
Session ID	{0861e55a-e29b-4b6f-825b-1e1d4c57f095}

Is it just me, or there’s something definitely wrong here?

That’s why I opened this bug on Microsoft Connect

Other Ways For Making PathInfo And ASP.NET Themes Work Together

Paulo Morgado — Fri, 25 Jul 2008 00:07:36 GMT

On my last post I wrote about a solution for the problem that arises when we try the use path infos and ASP.NET Themes and Skins together.

Raj Kaimal suggested rewriting all LINK HTML elements URLs to the correct URL as seen from the client. Something like this:

void HttpApplicationPreRequestHandlerExecute(object sender, System.EventArgs e)
{
    var httpApplication = sender as System.Web.HttpApplication;

    var httpContext = httpApplication.Context;

    var page = httpContext.CurrentHandler as System.Web.UI.Page;

    if ((page != null) && !string.IsNullOrEmpty(httpContext.Request.PathInfo))
    {
        page.PreRenderComplete += delegate(object source, System.EventArgs args)
        {
            var p = source as System.Web.UI.Page;

            foreach (System.Web.UI.Control headerControl in p.Header.Controls)
            {
                var link = headerControl as System.Web.UI.HtmlControls.HtmlLink;
                if (link != null)
                {
                    link.Href = p.ResolveUrl(link.Href);
                }
            }
        };
    }
}

With this approach you still have a problem (which mine didn’t solve) with post backs because the rendering of the ACTION of the HTML FORM is also broken.

Israel Aéce suggested the use of the BASE HTML element to re-base relative URLs. Something like this:

void HttpApplicationPreRequestHandlerExecute(object sender, System.EventArgs e)
{
    var httpApplication = sender as System.Web.HttpApplication;

    var httpContext = httpApplication.Context;

    var page = httpContext.CurrentHandler as System.Web.UI.Page;

    if ((page != null) && !string.IsNullOrEmpty(httpContext.Request.PathInfo))
    {
        page.PreRenderComplete += delegate(object source, System.EventArgs args)
        {
            page.Init += delegate(object source, System.EventArgs args)
            {
                var p = source as System.Web.UI.Page;

                var htmlBase = new System.Web.UI.WebControls.WebControl(System.Web.UI.HtmlTextWriterTag.Base);
                htmlBase.Attributes.Add("href", p.Request.Url.GetLeftPart(System.UriPartial.Authority) + p.Request.CurrentExecutionFilePath);
                p.Header.Controls.Add(htmlBase);
            };
        };
    }
}

This seems like the better solution except if your site sits behind several security perimeters and it is not possible to be sure what the domain is as seem from the client side, which was my problem to begin with.

But if you are thinking of calling Server.Execute, Server.TransferRequest or Server.TransferRequest, neither of these two solutions will work.

Making PathInfo And ASP.NET Themes Work Together

Paulo Morgado — Thu, 24 Jul 2008 00:13:00 GMT

Updated on 2008.07.28 – The code was done in a hurry and, talking to my friend Luís, I noticed that I had forgotten to make a case insensitive comparison and that the code was not so obvious. So, I updated the code and added an explanation.

On my last post I wrote about the problem that arises when we try the use path infos and ASP.NET Themes and Skins together.

But most of the times you don’t care about the why you can’t. You just want to know how you can.

The way I see it, the right solution would be to render the URLs for the stylesheets rooted.

But since I can’t do that, the next best thing is the serve the wrongly addressed request properly.

But how can we do that?

The only way I could come up with, was an HTTP Module:

public class AppThemesModule : global::System.Web.IHttpModule
{
    private const string LocalThemesFolderName = "/App_Themes/";
    private static readonly int searchStartIndex;
    private static readonly int minimumLenghtForSearch;

    static AppThemesModule()
    {
        int searchStartIndex = System.Web.HttpRuntime.AppDomainAppVirtualPath.Length;

        AppThemesModule.searchStartIndex = ((searchStartIndex == 1) ? 0 : searchStartIndex) + 2;

        AppThemesModule.minimumLenghtForSearch = AppThemesModule.searchStartIndex + AppThemesModule.LocalThemesFolderName.Length;
    }

    #region IHttpModule Members

    public void Dispose()
    {
    }

    public void Init(System.Web.HttpApplication context)
    {
        context.BeginRequest += HttpApplicationBeginRequest;
    }

    #endregion

    void HttpApplicationBeginRequest(object sender, System.EventArgs e)
    {
        System.Web.HttpApplication httpApplication = sender as System.Web.HttpApplication;

        string path = httpApplication.Request.Path;
        if (path.Length > searchStartIndex)
        {
            int appThemesStartIndex = path.IndexOf(AppThemesModule.LocalThemesFolderName, searchStartIndex, System.StringComparison.OrdinalIgnoreCase);
            if (appThemesStartIndex > 0)
            {
                httpApplication.Context.RewritePath("~" + path.Substring(appThemesStartIndex));
            }
        }
    }
}

The code starts by initializing the static read-only field searchStartIndex with the start index of the search for the /App_Themes/ pattern. If the length of the application’s virtual path is 1, that means that it’s the root of the site and search start index is 0 instead of 1; otherwise the search start index will be the length of the application’s virtual path. 2 is added because there is no need to start searching the path just after the application’s virtual path (if the pattern was found just after the application’s virtual path, no replacement would be needed).

Than, the static read-only field minimumLenghtForSearch is initialized with the minimum length of the path to search for the pattern. There is no need to search for the pattern on paths shorter than the search start index plus the length of the pattern because, if found, no replacement would be needed.

Besides registering the module, you’ll have to configure your virtual directory so that all the files to be served out of the themes are handled by a StaticFileHandler.

PathInfo And ASP.NET Themes: Why Can’t They Work Together?

Paulo Morgado — Wed, 23 Jul 2008 22:37:55 GMT

If you ever worked with ASP.NET Themes and Skins, you know that stylesheet links are added to the head section of the HTML document.

The rendered URL to these stylesheets is always relative to location of the page being requested.

So, for a request to:

http://MySite/Section/Default.aspx

you'll get:

which will make the web browser request for:

http://MySite/App_Themes/Default/Styles.css

and it all works fine.

Well, it works fine until you need to navigate to:

http://MySite/Section/Default.aspx/PathInfo

You'll get the same stylesheet reference and the browser will request for:

http://MySite/Section/Default.aspx/App_Themes/Default/Styles.css

This happens because the web browser has no knowledge of what PathInfos are. It only accounts for the number of forward slashes (/).

I've filed a bug on Microsoft Connect about this.

Make The HttpValueCollection Class Public And Move It To System.DLL

Paulo Morgado — Tue, 15 Jul 2008 00:22:30 GMT

I find the System.Web.HttpValueCollection class very useful in a wide number of situations that involve composing HTTP requests or any other need to represent name/value collection as a string (in an XML attribute, for example).

As of now (.NET Framework 3.5 SP1 Beta), the only way to create an instance of the System.Web.HttpValueCollection class is using the System.Web.HttpUtility.ParseQueryString method.

I’d like to see it public and available in a more generic assembly like System.DLL to be available on every type of .NET application (Windows Client applications, Windows Service applications, Silverlight applications, Windows Mobile applications, etc.).

If you agree with me, vote on my suggestion on Microsoft Connect.

BEWARE: System.Web.HttpValueCollection Parsing Is Not Reversible

Paulo Morgado — Mon, 14 Jul 2008 12:50:26 GMT

If you run this code:

System.Collections.Specialized.NameValueCollection queryString = System.Web.HttpUtility.ParseQueryString("noKey&=emptyKey&A=Akey");

queryString will actually have the running type of System.Web.HttpValueCollection.

What's great about this class is that its ToString method output is the collection's content in a nice URL encoded format.

As with its base class (NameValueCollection), there’s a difference between a null string and an empty string key and the parsing treats query string parameters with no parameter specification as having a null string key and parameters with an empty string key having an empty string parameter key.

So, when call ToString on the instance returned by System.Web.HttpUtility.ParseQueryString method you would expect to get the parsed string (or, at least, one that would be parsed into the equivalent collection), right? But what you’ll get instead is this: noKey&emptyKey&A=Akey.

I’ve filed a bug into connect. If you think this is important and must be corrected, please vote.

Isolator 4.3 Released!

Paulo Morgado — Wed, 02 Jul 2008 20:47:59 GMT

Today Typemock released version 4.3 of Typemock Isolator. Download it from here.

What’s new?

Support for Ivonna. For those of you who develop ASP.Net applications, Ivonna is a great tool, built on top of Isolator’s platform, to simplify writing tests for ASP.NET.
Typemock.Integration.Packs namespace APIs added to support license management through Isolator, the way Ivonna does.
As announced when it was released, version 4.2 was the last version of Isolator to support .NET 1.1. Version 4.3 only supports the 2.0 runtime and its Visual Studio counterparts: VS2005 and VS2008.
For 64 bit machines, now there’s a single installer. (don’t forget to uninstall both previous 32 and 64 installers prior to installing 4.3.)
RecorderManager.GetMockOf(instanceRef) and MockManager.GetMockOf(instanceRef). To retrieve the mock controller object based on a reference to the instance. (more...).

Bug fixes:

Fixes to DLINQ support. LINQ Queries with data tables now work better, for example with GroupBy.
Static constructors in Natural Mocks are now invoked correctly.
A bug that caused an exception to be thrown when mocking interfaces ("Method XX in type IMyInterface has no matching overload that returns TypeMock.Mock+a) was fixed.
A bug that caused an exception to be thrown when the mocked object was overriding Equals was fixed.
A bug that caused failure in mocking explicit interface with the same name was fixed.
A bug occurring im multithreading scenarios in VerifyWithWait was fixed.
A bug that causes NullReferenceException to be thrown when using Auto Deploy was fixed.

More On ASP.NET Validators And Validation Summary Rendering of Properties

Paulo Morgado — Mon, 23 Jun 2008 00:47:00 GMT

On previous posts [^][^] I mentioned the size of ASP.NET validators and validation summary rendering and the fact that expando attributes are being used to add properties. Mohamed also mentions this issue.

Besides the fact that custom attributes aren't XHTML conformant, Firefox differs from Internet Explorer in the way it handles these attributes.

On Internet Explorer, these attributes are converted in string properties of the HTML element. On Firefox, on the other hand, these attributes are only accessible through the attributes collection.

I wonder why I don’t like client-side JavaScript development.

Rendering ASP.NET Validators And Validation Summary Property As HTML Attributes

Paulo Morgado — Tue, 13 May 2008 00:34:00 GMT

Yesterday I blogged about the cause of ASP.NET validators and validation summary slowness.

At that point I wasn't aware of the existence of the XHTML conformance configuration (thanks Nuno).

With the XHTML conformance configuration set to Legacy, the rendering of controls works like it worked in ASP.NET 1.1.

The Cause Of ASP.NET Validators And Validation Summary Slowness

Paulo Morgado — Sun, 11 May 2008 23:17:00 GMT

When building ASP.NET pages, if you use too many validators and validation summaries your pages can become very slow. Have you ever wondered why?

Lets build a simple page web page with a few validators. Something like this:

The page is composed of:

2 TextBoxes
1 RequiredFieldValidator for each TextBox
1 RangeValidator for each TextBox
1 CompareValidator
1 ValidationSummary
1 Button

ASP.NET renders the ValidationSummary as a DIV and each validator as a SPAN and uses expando attributes to add properties to those elements.

According to the documentation, expando attributes are set dynamically from JavaScript to preserve XHTML compatibility for the rendered control's markup.

The problem is that all that JavaScript makes the HTML document larger and slower to execute than if the properties were rendered in HTML as attributes of the elements.

For such a small page, the difference in size approaches 2k bytes. If you add a few dozen validators to he page, the slowness is noticeable.

I'm all in favor of strict standards and standards compliance, but in this case, I wish XHTML would allow arbitrary attributes.

Upgrading the WCSF EventBroker Extension to WCSF 2.0

Paulo Morgado — Wed, 12 Mar 2008 00:15:10 GMT

While preparing the demos for my session at TechDays Portugal 2008, I've noticed some changes in the Web Client Software Factory 2.0 that prevented the EventBroker Extension from compiling and running.

The problem ended out just being a little change in the WebClientApplication class. The virtual methods related to creating the builders changed.

To fix this, all it's needed is editing the WebClientApplication class (CompositeWeb\WebClientApplication.cs, line 35).

Just replace the CreateBuilder override:

protected override Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilder CreateBuilder(bool isSingleton)
{
    // Our builder adds an EventBrokerStrategy to the build.
    WCSFBuilder builder = new WCSFBuilder();
    builder.Policies.SetDefault<ISingletonPolicy>(new SingletonPolicy(isSingleton));
    return builder;
}

with an override of the AddBuilderStrategies method:

protected override void AddBuilderStrategies(IBuilder<Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilderStage> builder)
{
    base.AddBuilderStrategies(builder);
    builder.Strategies.AddNew<EventBrokerStrategy>(Microsoft.Practices.CompositeWeb.ObjectBuilder.WCSFBuilderStage.PostInitialization);
}

Don't forget that if you want to run it in IIS7 Integrated Pipeline mode, you have a few more changes to make.

WCSF 2.0 And IIS7 Integrated Pipeline Mode

Paulo Morgado — Tue, 11 Mar 2008 10:06:00 GMT

While preparing the demos for my session at TechDays Portugal 2008, I've noticed that the Web Client Software Factory 2.0 doesn't work with IIS7 in integrated pipeline mode because it's trying to access the Request property of the current HTTP Context from the HTTP Application Start "event", which is not available at this point.

This is an already known issue and you can vote to get it solved.

Meanwhile, there are two ways to work around this:

Changing the Composite Web Application Block

If you are comfortable with having your own build of this block instead of the provided strong named one, you only need to change one statement in the WebConfigModuleInfoStore class (WCSFBlocks-Feb2008\CompositeWeb\Source\CompositeWeb\Services\WebConfigModuleInfoStore.cs, line 105).

Just replace:

configuration =
    WebConfigurationManager.OpenWebConfiguration(context.Request.ApplicationPath + "/" +
                                                 configFilePath.Replace(context.Request.PhysicalApplicationPath, ""));

with:

configuration =
    WebConfigurationManager.OpenWebConfiguration(HttpRuntime.AppDomainAppVirtualPath + "/" +
                                                 configFilePath.Substring(HttpRuntime.AppDomainAppPath.Length));

Changing the application

If you prefer to (or have to) use the provided and strong named version of the Composite Web Application Block, you can always change your application.

Just open the generated global.asax file:

<%@ Application Language="C#" Inherits="Microsoft.Practices.CompositeWeb.WebClientApplication" %>

and add:

<script RunAt="server">

    private bool initialized;

    protected override void Application_Start(object sender, EventArgs e)
    {
        this.initialized = false;
    }

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        if (!this.initialized)
        {
            this.initialized = true;

            base.Application_Start(sender, e);
        }
    }

</script>

Web Client Software Factory 2.0 shipped

Paulo Morgado — Fri, 29 Feb 2008 01:54:51 GMT

Web Client Software Factory 2.0

February 2008 Release

Resources

MSDN site: http://msdn.microsoft.com/webclientfactory
Community site: http://www.codeplex.com/websf

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

Paulo Morgado — Fri, 15 Feb 2008 00:40:43 GMT

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.