Modifying decade-old ASP.NET application

If you are planning to maintain an application for more than a decade then be careful.

I'm in middle of a case of modifying an ASP.NET WebForm application back to 2006 so 10 years old from now. This application is live for now and it is running for no problem. One month ago we migrated its hosting from Windows Server 2003 to Windows Server 2012 R2 successfully. I can imagine if no modification is needed it would be live for another more decade despite vast changing world of web development and .Net.

But our current problem is different than relocating it from a 2003 windows to a 2012 one. We want to modify it so change or add behaviors to it. Some modifications are easy to apply. For example if an HTML/CSS change is wanted it can be done by modifying ASPX/ASCX files easily. But modifications in code behind ASPX.CS and ASCX.CS file are not easy. Because our application is compiled and no CS file exists in hosting IIS. So changes must be applied in source code then published and converted to DLL files then deployed on the hosting IIS. Our application has dependencies to other assemblies like AjaxControlToolkit 2006 and we have not exact version of them currently. So our application simply wont build and wont publish easily.

At first glance I thought the only choice that we have is to upgrade all dependencies to current version that is impossible. From ten years ago til now many of third party libraries have been discontinued or have many breaking changes. Even ASP.NET itself has been changed very much. Fortunately I got a good solution. That was simple and trivial but I didn't noticed it before. We had published version of the application that means we currently have needed assemblies that are referenced from application. No matters if they are very old or we have not access to their source code. They are valid and executable .Net assemblies that can be referenced from any .Net application.

ASP.NET WebForm 2.0 work in Windows Server 2012 R2 again

There is a medium web application in the company that is in use since 2006 to now (2016). This web application is developed with ASP.NET Webform and .Net 2.0 in days of AjaxControlToolkit. For those unfamiliar with that, AjaxControlToolkit and UpdatePanel was an easy way for ASP.NET developers to make use Ajax, the hot technology of the day, in their web applications. Our company web application is hosted in a MS Windows 2003 and now must be hosted to a recent Windows version happened to be MS Windows 2012 R2. This story is about how we manage the application work again in new environment.

The application files copied to a folder in inetpub\wwwroot then an application created for it in IIS. Application was not working with .Net 2.0 App pool because of error “HTTP Error 404.17 – Not Found”. We decided to make it work with a .Net 4.0 App pool. The first error dumped was easy to handle. ASP.Net 4 has some entries of old web.config files into itself so was throwing error duplicate entries. This problem solved by removing those entries from web.config. After it the application get up correctly.

After some usage of the application we explored that some internal tabs are not opening after clicking. Guessing started here. The first guess was that IIS is not serving some file like a .js or a .css file correctly. It was no true because IIS logs and browser profilers did not record any relevant 404 error. Second guess was that something is wrong with AjaxControlToolkit. Our guess was that panels are changed with help of AjaxControlToolkit and UpdatePanel. I checked with Chrome's developer tool. No related console error existed. In another try I changed versions of System.Web.Extensions and AjaxControlToolkit to but didn't helped. Next time added assemblyBinding to web.config but this does not helped too. Event logs of Windows showed no suspicious item too. Several searches in Google neither helped too.

Being hopeless decided to debug client side code of the application in the Chrome developer tool despite of its 4.5K lines of code of legacy ASP.NET WebForm 2.0 application. Started my work by examining JavaScript function that was called by tab headers. javascript:__ShowTAB('ctl00_ContentPlaceHolder1_Panel3',3) was one of those functions. Tracing function calls showed that in an “if comparison” client Ids are not equal. I found it! Client Id generating was changed from .Net 2.0 to .Net 4.0. New one was shorter and didn't had prefix “ctl00_” in beginning of it. A StackOverflow question had same problem. A 2010 post of Scott Gu was showing the complete cause of the problem. ASP.NET 4 WebForm has been moved along a way to generate a cleaner client id. This behavior could be controlled via ClientIDMode. Unfortunately default value of this property was not AutoID while ASP.NET 2.0 behavior was as same as AutoID. I added ClientIDMode = AutoID to the directive of the master page and the problem solved peacefully.