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.
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 18.104.22.168 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.