> Something I've written 4 years ago will still run and compile like yesterday even if I've abandoned it in the mean while.
This.
I wrote a bunch of our (internal, non-internet facing) billing and automation code back in 2003 in C#1(.1?)/.NET 1.1. As we've gradually moved to .NET 4 the code still just works and when we need to it recompiles against newer framework versions with no errors.
Even the assembly of the Data Access Application Block [0] used back then for some of this stuff still works fine, the last time it was recompiled was for .NET 2.0 around 2006, but the IL runs without any trouble on .NET 4.6.
This is a mission critical codebase that doesn't change very often, but when it does it's imperative that it can when necessary rebuild against each major .NET framework update with no dramas.
Stability and confidence is key for us and MS have been very good at that, even when older features are deprecated/obsoleted.
Finally....
...just over two years ago when we were pushing the last of our hosted dedicated server customers to upgrade from Windows 2003 to Windows 2012R2 there were a few folks that were still running websites written in ASP.NET 1.1/.NET 1.1 on 2003. There were probably 40-50 sites and a sprinkling of Classic ASP just to make life interesting. Most customers didn't want to go through the hassle of recompiling and redeploying.
Now whilst there is a .NET 1.1 release you can run on Windows 2012, I really didn't want to be supporting three framework versions (1.1, 2.0/3.5 and 4.x) and CLRs. Having successfully migrated bucket loads of ASP.NET 1.1 sites to 2.0 in the past, from experience, I was fairly confident the 1.1 binaries would run just fine on .NET 2.0 which is the minimum version of .NET that ships in Windows 2012 and the IIS admin bits know about. After a week or so all of these old 1.1 sites were up and running on .NET 2.0 in IIS Classic Pipeline app pools, no recompilation needed and except for one site that used an ancient third party PDF component, all was well in the world.
Now whilst .NET may seem unexciting enterprisey stuff, it's a testament to how much the .NET folks care about stability and backwards compatibility. I'm fairly sure, and I know for sure, I couldn't do these seamless transitions if these codebases were written in PHP (for example).
This.
I wrote a bunch of our (internal, non-internet facing) billing and automation code back in 2003 in C#1(.1?)/.NET 1.1. As we've gradually moved to .NET 4 the code still just works and when we need to it recompiles against newer framework versions with no errors.
Even the assembly of the Data Access Application Block [0] used back then for some of this stuff still works fine, the last time it was recompiled was for .NET 2.0 around 2006, but the IL runs without any trouble on .NET 4.6.
This is a mission critical codebase that doesn't change very often, but when it does it's imperative that it can when necessary rebuild against each major .NET framework update with no dramas.
Stability and confidence is key for us and MS have been very good at that, even when older features are deprecated/obsoleted.
Finally....
...just over two years ago when we were pushing the last of our hosted dedicated server customers to upgrade from Windows 2003 to Windows 2012R2 there were a few folks that were still running websites written in ASP.NET 1.1/.NET 1.1 on 2003. There were probably 40-50 sites and a sprinkling of Classic ASP just to make life interesting. Most customers didn't want to go through the hassle of recompiling and redeploying.
Now whilst there is a .NET 1.1 release you can run on Windows 2012, I really didn't want to be supporting three framework versions (1.1, 2.0/3.5 and 4.x) and CLRs. Having successfully migrated bucket loads of ASP.NET 1.1 sites to 2.0 in the past, from experience, I was fairly confident the 1.1 binaries would run just fine on .NET 2.0 which is the minimum version of .NET that ships in Windows 2012 and the IIS admin bits know about. After a week or so all of these old 1.1 sites were up and running on .NET 2.0 in IIS Classic Pipeline app pools, no recompilation needed and except for one site that used an ancient third party PDF component, all was well in the world.
Now whilst .NET may seem unexciting enterprisey stuff, it's a testament to how much the .NET folks care about stability and backwards compatibility. I'm fairly sure, and I know for sure, I couldn't do these seamless transitions if these codebases were written in PHP (for example).
[0]: https://msdn.microsoft.com/en-us/library/ff649538.aspx