This is just the decay of knowledge over time and laziness combined.
From a quick glance internally, the overwhelming majority of repos are using an antiquated build/packager that while it might have been useful a decade ago is a productivity killer today.
The newer build / package system used publicly is light years ahead and provides a boon in productivity.
Not really sure why so many services in MSFT still run .NetFramework when “just” migrating over can lead to sometimes order of magnitude increase runtime performance and decreased resource consumption.
I think one of the real reasons is internally, most of the leads aren’t aware of it. There should be more evangelizing of the .NET team across the different orgs
From a quick glance internally, the overwhelming majority of repos are using an antiquated build/packager that while it might have been useful a decade ago is a productivity killer today.
The newer build / package system used publicly is light years ahead and provides a boon in productivity.
Not really sure why so many services in MSFT still run .NetFramework when “just” migrating over can lead to sometimes order of magnitude increase runtime performance and decreased resource consumption.
I think one of the real reasons is internally, most of the leads aren’t aware of it. There should be more evangelizing of the .NET team across the different orgs