|
|
|
|
|
|
by wickedshimmy
5303 days ago
|
|
|
Don't see how the relevance or presence of XAML/WPF affects the use of the rest of the framework and the BCL, and I would be shocked to hear about your backwards compatibility issues between running compiled assemblies on different CLR versions. Also, I think you mean .NET 4.5 in Windows 8 - .NET 4.0 was released over a year and a half ago, and runs most legacy applications perfectly well. |
|
|
As for the "shocking" backwards compatibility issues - they're very well documented. Compiling against .NET 2.0 in VS2010 gives you access to certain methods and overloads that were not present in the initial .NET 2.0 release, but were added in SP2 and SP3. Which is cool... What's not cool is that a) there is no official list of methods added between the SPs to the best of my knowledge (but I really could be wrong here!), and more importantly b) the resulting application which actually requires .NET 2.0 SP2/3 will run on .NET 2.0 RTM (for example), and you'll have ZERO indication that it's broken until during runtime when you try to call a particular method or overload that was not present in the version of the framework you're on, when you'll get some generic exception instead. Good luck figuring that one out from the anonymous crash dumps you'll receive by email.
A proper approach would have been the option to select which SP of the Framework you wish to compile against or at the very least, generate warnings during compile that your use of function X will CRASH on .NET 2.0 SP1, for example. That, and proper detection of out-of-date .NET runtimes (a la SxS - which while a real PITA at least makes sense) instead of silent, nasty runtime crashes when using mismatching versions.
Off the top of my head, I recall that the Auto/Manual reset event classes have either methods or overloads that were modified between SPs.