> There are a ton of folks that have invested a ton
> of time and their livelihood into the apps that
> they've bet on our platform. What do you want me
> to tell them?

They "invested a ton of time and their livelihood" into version X. When version Y comes along, why should they honestly expect their application to run flawlessly untested and unverified? As much as Microsoft tries to keep backward compatibility, no one can honestly expect their application to run on a new version without re-testing and verifying that it actually functions correctly.

What ever happened to .Net versioning? Run your application under the version that it was designed and tested for. There is no such thing as a free upgrade, as much as you try to accomplish.

Compatibility is my number one issue with developing for Microsoft platforms. Errors and problem-spots are identified, but they are generally not fixed. This propagates for years and years. .Net 1.0 was a awesome precisely because it did not have any of the backward compatibility to worry about. However, that all changed when 1.1 and subsequent versions were released. Same with Silver Light 1.0.

Do not punish the rest of us for all time. Clean up the trash.

As a developer, I have had nothing but negative experiences with compatibility. At two companies that I have worked for in the past, managers declared that an existing product (one for Windows 95, another for .Net 1.0) would work on new versions (Windows 2000 and .Net 2.0, respectively) without any testing. I argued that we need to at least test it, but several managers over-ruled me saying that Microsoft maintains backward compatibility and that they did not have the time or resources to devote to the task. I knew we were in for a world of hurt, and sure enough, over the next few months we were flooded with support calls.

At a few other companies, actual testing was done. However, when issues were found, management decided to modify the specification rather than fix the real issues.

Many smaller companies simply do not test and verify their applications on new versions. You're selling a fantasy (whether intended or not), and management is buying it, often at great costs down the road.

That being said, though, my biggest issue with backward compatibility is that it makes it difficult to program against. I probably spend a good 40% of my development time reading about historical reasons why an API does not work as I imagine it should, and then trying to figure out which hack I need to use to make it do so. I really (really!) wish some of these APIs would be either 1) rewritten correctly even if it breaks older code or 2) depreciated or better simply removed.

Much of this could be solved with more interfaces and unsealed base classes. You could maintain your legacy code while letting developers re-implement base types as seen fit. However, the main types that I have problems with do not implement common interfaces or are often sealed.

The huge jump in productivity that I got from .Net 1.0 gets smaller and smaller with each new release. I sometimes wonder how productive I would have been with the initial Windows 1.0 API had I started back then compared to the ugliness of Win32. now I am already hoping for a new, clean library to replace the dirty BCL.

I agree with the above poster: .Net applications should run on the version that they were designed and targeted for. Break / fix future versions as much as needed. Do not let compatibility become the excuse for not taking action.