Thursday, November 27, 2014     •  Login
   Welcome to my blog! Minimize
Author: Daniel Balla Created: Fri, 13 Jun 2008 22:20:41 GMT
/// <summary>
/// Various posts on software design and development
/// </summary>
class Blog<T> where T : ASP.NET, Ajax, WCF, SOA, new()

By Daniel Balla on Mon, 13 Jun 2011 19:25:04 GMT

I didn't blog for so long that I forgot my password :)

Anyway, back to the issue at hand, I've wasted so much time troubleshooting this environment that it is worth posting about it. This is the case of the ASP.NET application losing state in a web farm environment. The scenario is a straight-forward ASP.NET application deployed in a farm with a load balancer in front.

The problem was that the application was losing state in between requests. My findings are summarised in the check-list below.

  •  Check the session state access. You are most likely using the SQL server session state so check the connection strings and ensure that the ports are open from each web node to the database.
  •  Assuming that you are not using sticky sessions, and that you use Forms Authentication and/or have EnableViewStateMAC enabled (which you should) ensure
  • Read More »

By Daniel Balla on Fri, 23 Mar 2007 18:57:03 GMT

A couple days ago a friend asked me how can you make the ASP.NET validators validate the contents of a gridview at row level, so that each row works independently. For example, in the grid below use a requiredfieldvalidator on each row so that the Save button would validate the description textbox on the same row, but wouldn’t validate any of the other rows’ descriptions.

In this case, clicking the save button in the “Dairy products” row would cause the validation to suppress the postback, but clicking the save button of any other row wouldn’t.
The solution is simple: use the validation group bound to a unique row identifier. In our example (which displays the contents of the Categories table of the Northwind database) the binding would look like:

<asp:TextBox Width="300px" ID="txtDescription" runat="server" Text='<%# Bind<"Description"> %>' />
<asp:RequiredFieldValidator ID="reqDescription" runat="server" ControlToValidate="txtDescription" ErrorMessage="*" ValidationGroup='<%# Bind<"CategoryID"> %>' />
<asp:Button ID="butSave" runat="server" Text="Save" ValidationGroup='<%# Bind<"CategoryID"> %>' />

Download Sample Code

By Daniel Balla on Wed, 22 Nov 2006 18:55:59 GMT

This is neither a very common scenario nor a major finding, just a small reminder/warning to spare you a little debugging for one of those things that are fairly obvious yet could take some time to see.
While helping a friend figure out why his ASP.NET no longer works after "atlasising" it I came across this issue:
The page was throwing the following exception:

Script controls may not be registered before PreRender.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidOperationException: Script controls may not be registered before PreRender.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[InvalidOperationException: Script controls may not be registered before PreRender.]
Microsoft.Web.UI.ScriptControlManager.RegisterScriptControl(TScriptControl scriptControl) +144
Microsoft.Web.UI.UpdateProgress.OnPreRender(EventArgs e) +140
System.Web.UI.Control.PreRenderRecursiveInternal() +77
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Control.PreRenderRecursiveInternal() +161
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1360

As the page worked before it had the atlas references and an update panel added (and out of laziness) instead of properly reading the source code I proffered to google the error and the only relevant result was where the suggestion was that an older version of the DLL might be cached somewhere. Here is where I went wrong and spent a lot of time clearing and rebuilding. On a second look, I found that the page's OnPreRender method was overridden and it didn't call the base OnPreRender method therefore loosing some handlers. Obviously this mistake didn't do much difference before atlas came into play but it did afterwards because the Atlas ScriptControlManager's RegisterScriptControl method doesn't register the control but after prerender (by checking a flag it sets on prerender)

public void RegisterScriptControl(TScriptControl scriptControl) where TScriptControl: Control, IScriptControl
if (scriptControl == null)
throw new ArgumentNullException("scriptControl");
if (!this._pagePreRenderRaised)
throw new InvalidOperationException(AtlasWeb.ScriptControlManager_RegisterScriptControlTooEarly);

public void OnPagePreRender(object sender, EventArgs e)
this._pagePreRenderRaised = true;

By Daniel Balla on Tue, 21 Nov 2006 13:09:38 GMT

Seldom, but still a possible scenario: when trying to preview the generated service description for an asmx web service (both .NET 1.1 and .NET 2.0) you might get an error that is not very well described:

Line 1334: OperationBinding FindHttpBinding(string verb) {
Line 1335: foreach (ServiceDescription description in serviceDescriptions) {
Line 1336: foreach (Binding binding in description.Bindings) {
Line 1337: HttpBinding httpBinding = (HttpBinding)binding.Extensions.Find(typeof(HttpBinding));

The real issue is that in your web application’s web.config file in the pages element you probably have the autoEventWireup attribute set to false
<pages … autoEventWireup="false"…

If you want to trace the problem, you can open the DefaultWsdlHelpGenerator.aspx file (located under %windir\Microsoft.NET\Framework\[version]\CONFIG\DefaultWsdlHelpGenerator.aspx) and you would notice that the error is that the serviceDescriptions member is used without being initialized (therefore the null object reference exception). Looking up in the page you notice that the serviceDescriptions member is initialized
serviceDescriptions = (ServiceDescriptionCollection) Context.Items["wsdlsWithPost"];
serviceDescriptions = (ServiceDescriptionCollection) Context.Items["wsdls"];)
in the Page_Load method. However, because your settings disable the autoeventwireup that prevents the Page_Load methods from being called (it is not explicitly wired to the page load event so it relies entirely on the autoeventwireup feature).

Surely this isn’t a big finding and it wouldn’t save you more than 5 minutes of debugging but it is worth mentioning because it is a “red wiring” in the framework.

By Daniel Balla on Mon, 02 Oct 2006 21:55:16 GMT

Indeed, most times you write the events at a time, maybe in a region and the trigger methods afterwards in another region; but then you do the same with local fields and properties, and yet the prop snippet comes in handy. Therefore I thought a simple event code snippet would be useful. You can download it here and then copy it to your Program Files\Microsoft Visual Studio 8\VC#\Snippets\1033\Visual C#\ directory

or, copy/paste from below:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="">
<CodeSnippet Format="1.0.0">
<Description>Code snippet to created and document an event</Description>
<Author>Daniel Balla</Author>
<ToolTip>Event name</ToolTip>
<ToolTip>Event arguments type</ToolTip>
<Code Language="csharp"><![CDATA[#region Event Handler $event$ ($eventArgs$)
/// <summary>
/// This event is fired when |
/// </summary>
public event EventHandler $event$;
#region Event notification $event$
/// <summary>
/// Notifies the listeners of the $event$ event
/// </summary>
/// <param name="e">The argument to send to the listeners</param>
protected virtual void On$event$($eventArgs$ e) {
if($event$ != null) {

   Archives Minimize
   Search Blog Minimize