In unsere Onlinesysteme haben wir einen Mechanismus implementiert, um auftretende Exceptions zu loggen. So finden wir Fehler, die wir mit unseren Tests nicht abdecken konnten oder an die wir nicht gedacht haben.

In meinen Protokollen finde ich nun immer wieder Exceptions vom Typ System.Web.HttpException, die in der Klasse System.Web.Configuration.MachineKeySection und der Methode GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength) geworfen werden.

Der vollständige StackTrace wäre

System.Web.Configuration.MachineKeySection
    GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)
System.Web.UI.ObjectStateFormatter
    Deserialize(String inputString)

Ich konnte diese Exception nie reproduzieren und recherchierte nach der Ursache.
Ich fand heraus, dass diese Exception geworfen wird, wenn der User einen Request an den Webserver abbricht. Der IIS nimmt den POST-Request entgegen und leitet ihn an ASP.NET weiter, obwohl der Request nicht vollständig angekommen ist.
Ein Beispiel hierfür wäre, wenn der User ein PostBack durch einen Button-Click veranlasst, dann aber bei seinem Browser auf “Abbrechen” drückt oder einfach zur vorherigen Seite wechselt.
In diesem Fall kommt der Request nicht vollständig beim IIS an, die Teildaten werden aber dennoch an ASP.NET weitergereicht.
Klar, dass die Deserialisierung von unvollständigen Daten fehlschlagen muss und so wird die o.g. Exception ausgelöst.

Für uns als Entwickler ist das kein Grund zur Beunruhigung, der User bekommt von der Exception nichts mit, wir können sie also getrost ignorieren.

PartialUpdatePanel got some massive improvements in the current release!
Here are some of them

• Added encryption support for UserControl path
• Added support for custom ScriptManager types (includes ToolkitScriptManager)
• Added support for ToolkitScriptManager.CombineScriptsHandlerUrl
• Change UserControlPath using JavaScript during runtime
• Manipulate Parameters serverside during roundtrip
• Fixed issue using validators and rendering in Clientside mode
• Fixed a bug with recreating components
• Added some more demos to show the new features

Attention: If you use this version, you have to make some changes in your code:

• web.config: Add (with user defined value of course)

  <appSettings> 
      <add key="PartialUpdatePanel.EncryptionKey" value="k39#9sn1"/> 
  </appSettings>

• The use of parameter collection changed.

  new iucon.web.Controls.ParameterCollection()

  is no longer supported. Use

  iucon.web.Controls.ParameterCollection.Instance

  instead

You can find an updated version of the PartialUpdatePanel ASP.NET-Control here: PartialUpdatePanel 1.6.

So what is the PartialUpdatePanel?
The PartialUpdatePanel provides real partial rendering of ASP.NET pages.
By using this control you can experience performance improvements compared to ASP.NET AJAX UpdatePanel, because not all page data needs to be transferred. Only a minimal set of data is being transported between the client and the server before your UserControl is made fully functionable.

Usage scenarios
Exemplary scenarios for the usage of the PartialUpdatePanel are:

• Autonomous sections of your page that require PostBack-support but not the environment information of the entire web page (e.g. data lists with paging support where the user can browse through news, feeds, mails, etc.)
• User feedback when your control has to complete long operations. In this case use a PartialUpdatePanel with render method “Clientside”. The surrounding page will be displayed with a waiting message. The user will receive an adequate feedback that something is going on and he needs to wait until it is done.

More information and a version history can be found here: http://www.codeplex.com/PartialUpdatePanel.

On codeproject I wrote an indepth technical article how the PartialUpdatePanel works: http://www.codeproject.com/KB/ajax/PartialUpdatePanel.aspx

Imagine you have the following declaration

<asp:Content ContentPlaceHolderID="plcMainContent" ID="cntMain" runat="server">
    ...
    <asp:Panel id="pnlThumb1" runat="server" Visible="true"/>
    ...
</asp:Content>

and you are calling in your CodeBeside

this.pnlThumb1.Visible = false;

it will simply work without any problem.
Now think about changing your call to

this.FindControl("pnlThumb1").Visible = false;

what happens? You will get a NullReferenceException!
What you can do is first get a reference to your Content and second make a FindControl call:

ContentPlaceHolder mainContent = (ContentPlaceHolder)this.Master.FindControl("plcMainContent");
mainContent.FindControl("pnlThumb1").Visible = false;

This works, but this workaround is not very elegant.
We can get more elegance to our code by using reflection and a simple extension class.
The basic idea behind the following code is, that ASP.NET generates protected Control declarations for every control in the page. So we can get references to the controls by reflecting into the class instead of using FindControl.

public static class PageExtensions
{
        public static T GetControl<T>(this Page page, string name) where T : Control
        {
            FieldInfo field = page.GetType().GetField(name, System.Reflection.BindingFlags.IgnoreCase | System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
            if (field != null)
                return (T)field.GetValue(page);
 
            return null;
        }
}

The usage now is quite simple:

this.GetControl<Panel>("pnlThumb1").Visible = false;

Will man von einer Content Page auf Controls der MasterPage zugreifen, so ist die erste Idee oft die Nutzung von MasterPage.FindControl. Klar, das funktioniert. Nur stellt sich die Frage, ob das nicht schöner geht? Bevor dieser Frage auf den Grund gegangen wird, soll das Problem kurz an einem Beispiel veranschaulicht werden:

MasterPage.master:

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>
<html>
<body>
    <form id="form1" runat="server">
        <asp:TextBox runat="server" ID="TextBoxMaster" />
        <asp:ContentPlaceHolder ID="ContentPlaceHolderMain" runat="server">
        </asp:ContentPlaceHolder>
    </form>
</body> 
</html>

Das Ziel soll nun sein aus einer Content Pager heraus, möglichst elegant auf die TextBox “TextBoxMaster” zuzugreifen. Perfekt wäre also ungefähr so etwas:

protected void Page_Load(object sender, EventArgs e)
{
    Master.TextBoxMaster.Text = "Hello world";
}

Leider funktioniert das so auf Anhieb nicht. Das erste Problem ist, dass hierfür der Compiler wissen müsste, welches der Typ der MasterPage ist, der von der Content Page referenziert wird. Da man aber die MasterPage zur Laufzeit zuweisen kann, kommt man hiermit nicht so recht weiter…
Oder? Da wurde doch in ASP.NET 2.0 eine neue Seiteneigenschaft MasterType eingeführt, die sollte doch genau das Problem lösen und zur Compilezeit den Typen der MasterPage bekannt machen!

<%@ Master Language="C#" MasterPageFile="~/MyMasterPage.master" AutoEventWireup="true"
    CodeFile="MyMasterPage.master.cs" Inherits="contentPage"  %>
 
<%@ MasterType VirtualPath="~/MyMasterPage.master" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolderMain" runat="Server">
    Inhalt der Content Page
</asp:Content>

Der Ansatz ist gar nicht so falsch. Jetzt weiß der Compiler uns auch IntelliSense schonmal, welche Eigenschaften und Methoden zur referenzierten MasterPage gehören.
Doch leider führt der Aufruf von Master.TextBoxMaster wieder ins Nirvana.
Der Grund hierfür ist, dass alle Controls einer Seite (der MasterPage eingeschlossen) standardmäßig die Sichtbarkeit protected tragen. Die gute Nachricht ist: das können wir ändern!

Ganz ohne Arbeit geht es leider nicht, doch die hält sich in Grenzen.

Schritt 1:
Entfernen der partial-class-Deklaration. Dies soll ASP.NET beibringen, dass nur noch eine Code-Datei für die MasterPage existiert und keine temporäre mehr für die Control-Deklarationen zur Compilezeit erzeugt werden muss.

Schritt 2:
Deklarieren der Controls mit der public-Sichtbarkeit.

public class MyMasterPage : System.Web.UI.MasterPage
{
    public TextBox TextBoxMaster;
}

Schritt 3:
Ändern der @Page Direktive: Tausche Inherits durch CodeBaseFileClass und verschiebe die CodeBehind-Datei in das Verzeichnis App_Code.

<%@ Master Language="C#" MasterPageFile="~/MyMasterPage.master" AutoEventWireup="true"
    CodeFileBaseClass="MyMasterPage" %>

Schritt 4:
Ausführen des lang ersehnten Codes in der Content Page

protected void Page_Load(object sender, EventArgs e)
{
    Master.TextBoxMaster.Text = "Hello world";
}

You can find an updated version of the PartialUpdatePanel ASP.NET-Control here: PartialUpdatePanel 1.5.4.

So what is the PartialUpdatePanel?
The PartialUpdatePanel provides real partial rendering of ASP.NET pages.
By using this control you can experience performance improvements compared to ASP.NET AJAX UpdatePanel, because not all page data needs to be transferred. Only a minimal set of data is being transported between the client and the server before your UserControl is made fully functionable.

Usage scenarios
Exemplary scenarios for the usage of the PartialUpdatePanel are:

• Autonomous sections of your page that require PostBack-support but not the environment information of the entire web page (e.g. data lists with paging support where the user can browse through news, feeds, mails, etc.)
• User feedback when your control has to complete long operations. In this case use a PartialUpdatePanel with render method “Clientside”. The surrounding page will be displayed with a waiting message. The user will receive an adequate feedback that something is going on and he needs to wait until it is done.

More information and a version history can be found here: http://www.codeplex.com/PartialUpdatePanel.

On codeproject I wrote an indepth technical article how the PartialUpdatePanel works: http://www.codeproject.com/KB/ajax/PartialUpdatePanel.aspx