The web application we have been upgrading uses the Microsoft UIProcess Application Block. When we develop we usually use local IIS rather than the Visual Studio web server because this flushes out permissions problems more quickly, and in a large development team you don't end up with people inadvertently changing the server ports on the local web sites and thus screwing up everyone's service references. In turn, using IIS means that all of your web projects tend to be in separate virtual directories under the web root, and so we never ran the application as a rot website.
Now, one of my team then went to deploy the application for testing on the client's site and the client requested that it was deployed in a separate website on a different port number. So far so good, we have to perform the install and then manually change the root website's home directory but no great shakes here. Then on testing it was found that the UIProcess was failing. This is because of a bug in the way that it is coded, where the code assumes that there is a virtual directory and does not handle being in the root website.
More details on a proposed fix are here: http://weblogs.asp.net/sebastianweber/archive/2004/03/03/83163.aspx
We didn't actually implement the fix line for line, because I did not want to have to change the config as per the fix, but it was enough of a pointer to get started.
It's amazing really how these things come back to bite you. Working for a Microsoft Gold Partner, I usually feel that I am working on fairly cutting-edge stuff most of the time, and occasionally a project like this comes along with some old technology that's too deeply embedded to strip out, and all sorts of probems arise. Not least because no-one is using these application blocks any more (are they? are you?).
No comments:
Post a Comment