In my job as a PFE for Microsoft, I read, review and fix a lot of code.  A lot of code.  It’s a large part of what I love about my job.  The code is generally written by large corporations or for public websites.  Every now and again I’ll get pinged on an issue and after troubleshooting the issue, it’s pretty clear that the core issue is with some community code.  When I say community code, in this instance, I don’t mean a CodeProject or CodePlex project.  In this case, I am referring to a control that Denis Bauer created and then made available to the community on his website – the “DynamicControlsPlaceholder” control.  This is a great little control that inherits from a PlaceHolder and allows you to  create dynamic controls on the fly and then it will persist the controls you add on subsequent requests – like a postback.

The Problem

The customer was experiencing a problem that could only be replicated in a web farm when they don’t turn on sticky sessions.  They found that when a request went from one server to another server in their farm they would get a FileNotFoundException with the following details:

Type Of Exception:FileNotFoundException

Message:Error on page http://blahblahblah.aspx

Exception Information:System.IO.FileNotFoundException: 


Could not load file or assembly 'App_Web_myusercontrol.ascx.cc671b29.ypmqvhaw, 


Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. 


The system cannot find the file specified.

File name: 'App_Web_myusercontrol.ascx.cc671b29.ypmqvhaw, 


Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

at System.RuntimeTypeHandle.GetTypeByName(String name, 


Boolean throwOnError, 


Boolean ignoreCase, 


Boolean reflectionOnly, 


StackCrawlMark& stackMark)

...

at DynamicControlsPlaceholder.RestoreChildStructure(Pair persistInfo, 


Control parent)

at DynamicControlsPlaceholder.LoadViewState(Object savedState) 


at System.Web.UI.Control.LoadViewStateRecursive(Object savedState)

...

at System.Web.UI.Control.LoadViewStateRecursive(Object savedState)

at System.Web.UI.Page.LoadAllState()

at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, 


Boolean includeStagesAfterAsyncPoint)

So, we can gleam a few things from the error details:

• They are using the ASP.NET website model (the “app_web_….dll” assembly is the clue).
• The error is occurring in the RestoreChildStructure method of the DynamicControlsPlaceholder control.

The Research

The way that ASP.NET Websites work is that each component of your site can be compiled into a separate assembly.  The assembly name is randomly generated.  This also means that on two servers, the name of the assemblies can end up being different.  So, an assumption to make is that something is trying to load an assembly by its name.  If we look at the RestoreChildStructure method, we see the following:

            

Type ucType = Type.GetType(typeName[1], true, true);

try

{

MethodInfo mi = typeof(Page).GetMethod("LoadControl", 

new Type[2] { typeof(Type), typeof(object[])
});

control = (Control) mi.Invoke(this.Page, newobject[2]
{ ucType, null });

}
catch (Exception e)

{
thrownew ArgumentException(String.Format("The
type '{0}' …", 


ucType.ToString()), e);

}

The important thing to look at here is the Type.GetType(…) call.  Since the code for the control is in a separate assembly from everything else, the “typeName[1]” value MUST BE A FULLY QUALIFIED ASSEMBLY NAME.  From the exception details, we can see that it is attempting to load the type from the following string:

App_Web_myusercontrol.ascx.cc671b29.ypmqvhaw, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

The “typeName[1]” variable is loaded from ViewState because that’s where the control persists its child structure.  So, for some reason the fully qualified assembly name is stored in ViewState.  If we look at the code that inserts the value into ViewState (in the PersistChildStructure(…) method), we see:

            

typeName = "UC:" + control.GetType().AssemblyQualifiedName; 

So, here we see the AssemblyQualifiedName is being stored into ViewState – which is then used to persist the controls across postback using the above code.  As I mentioned, this won’t work with an ASP.NET website hosted in a web farm because the assembly qualified name will probably be different from server to server.  We even have a KB article that discusses this issue somewhat. 

The Fix

Fortunately, the fix is pretty simple. 

First, we need to store the path to the User Control instead of the AQN in ViewState.  To do this, you can comment out the “typeName = ….” line from directly above and replace it with:

            

UserControl uc = control as UserControl;

typeName = "UC:" + uc.AppRelativeVirtualPath;

So, now we store the path to the UserControl in ViewState.  Then, we need to fix the code that actually loads the control.  Replace the code from above in the RestoreChildStructure(…) method with this code:

            

            string path = typeName[1];

try

{

control = Page.LoadControl(path);

}
catch (Exception e)

{
thrownew ArgumentException(String.Format(
"The type '{0}' cannot be recreated from ViewState", 


path), e);

}

That’s all there is to it.  Just load the user control from where it is being stored in the site and ASP.NET will take care of loading the appropriate assembly.

Enjoy!

First, a few questions:

• Do you enjoy helping developers write better code?
  
• Do you enjoy solving complex problems that span multiple technologies?
  
• Do you enjoy optimizing and improving code?
  
• Are you passionate about software development?
  
• Do you enjoy managing your own calendar?
  
• Do you want to make the world a better place?

If the answer to these questions is “YES!”, then please read-on.

We are now actively recruiting for 3 Developer Premier Field Engineering positions at Microsoft. 

You may ask yourself, what does a Dev PFE do?

We do both proactive and reactive work encompassing a variety of Microsoft’s developer products.  In general, the reactive work is where a customer is experiencing a problem (usually in production) and they need someone onsite to help them resolve the issue. The proactive work usually takes the form of knowledge transfer to companies on how they can improve the maintainability of their code, how to debug problems and how to optimize their applications.  I have also done a fair number of “proofs of concept” for customers where they just don’t know how to do something or they want me to prove that it can be done. 

In the past year, I’ve worked on projects using .NET (1.1 – 4.0), Windows Azure, Internet Explorer, Bing, Bing Translator, Windows 7 and many others. 

And the list really does go on.  You will work with our largest customers around the world helping them write better code, solving complex issues, teaching them about the latest technology and just making the world a better place.

If this sounds like a good fit for you, click here to go to the Microsoft Careers site to apply.