Three Dirty Steps to Fix UI Process Bug
In a prior post I told about the Incredible Bug in Microsoft's User Interface Block and I've linked to a bug fix from Steve. The following solution is Steve's solution. I've wrapped it up in a more colored style :-)
The actual release has a problem when application runs in web root and not in a virtual directory, as you can see in next line:
HttpContext.Current.Response.Redirect( HttpContext.Current.Request.ApplicationPath + "/" + viewSettings.Type + "?" + queryString,
true );
A root context Request.ApplicationPath will return "/" and the expression above tries to redirect to "//MyView.aspx?...".
In order to fix this bug you have to follow these three steps:
1. Fix ActivateView-Method in WebFormViewManager.cs
// Old implementation:
if (previousView == null )
HttpContext.Current.Response.Redirect( HttpContext.Current.Request.ApplicationPath + "/" + viewSettings.Type + "?" + queryString, true );
else
HttpContext.Current.Response.Redirect( HttpContext.Current.Request.ApplicationPath + "/" + viewSettings.Type + "?" + queryString, false );
// New implementation:
string path = HttpContext.Current.Request.ApplicationPath;
if (path == "/")
path = "";
if( previousView == null )
HttpContext.Current.Response.Redirect( path + viewSettings.Type + "?" + queryString, true );
else
HttpContext.Current.Response.Redirect( path + viewSettings.Type + "?" + queryString, false );
Of course, you can replace the last if-Statement by a single line by replacing true and false with the expression previousView == null ...
2. Fix IsRequestCurrentView-Method in WebFormViewManager.cs
// Old implementation:
string viewType = page.Request.CurrentExecutionFilePath.Replace(page.Request.ApplicationPath + "/", "");
// New implementation:
string path = page.Request.ApplicationPath;
if (path != "/")
path = "";
string viewType = page.Request.CurrentExecutionFilePath.Replace(page.Request.ApplicationPath + path, "");
3. Add leading "/" in Web.config
The third and maybe the most problematic step is to add leading slashes in Web.config file for view paths. It might be problematic because you have to take care about your UI-Process Version and the underlying Web.config definitions otherwise the application crashes in a virtual directory and in a root context.
// Old:
<views>
<view name="Homepage" type="default.aspx" controller="Default" />
</views>
// New:
<views>
<view name="Homepage" type="/default.aspx" controller="Default" />
</views>
To-do
Unfortunately I didn't have a closer look at the sources but there should be a solution without editing the web.config files. It's never good to change an interface and also to change configuration specification ...