You can implement side by side compatibility- and we've had to do that. But it's something you have to do. And it doesn't work for C++ libraries that you might be linking to that do not link to the correct .NET framework version.
Understood, it's just something I threw in as a curiosity since I just ran across it and was toying on using it for a -(fake virus)- project I'm working on.
And there are changes between .NET versions. I know because I've had to go through this before, and the behavior of initialization of certain complex types changed between major versions. And then there's the idea of third-party libraries you can't just recompile. I've had that problem too.
Right... Wasn't really eyeing that can of worms...as it's part of why I clung to pure Win32 API programming for so long. I'd seen way to many issues with the VB runtimes 3, 4, 5 to even consider trying to code anything that was going to be dependent on a runtime package...or anything that looked like one.
And you can tell what .net framework things are compiled for, so even if you were to have your theoretical call, and they started to help you... once you got down to it and they say what it was compiled for, you'd be out of luck.
Now it's possible that you've had a bad experience in the past that I don't have available to pull from. But I just don't read it that way. To me it seems that all they are saying is that if you have an issue with a currently installed copy of the .NET framework 4.0...they won't support it. Okay, but if you have an issue with a currently installed copy of the .NET framework 4.5.2 they will support it.
...Work with me here - I'm trying to understand something...
Pretend we have two different installer files:
1. Is a Windows 8 era copy of the .NET4.0 framework ... that I believe we can safely assume is not going to be currently "supported".
2. Is a copy of the latest issue copy of the .NET4.5.2 framework ... That also happens to include 4.0..
So, are you telling me that the - as request-able by/for the application - 4.0 that is included in 4.5.2 is quite likely to behave differently - at runtime - than the Win8 era .NET40 framework installer version of -(what appear to be allegedly)- the same 4.0 framework?
But what I'm really talking about is security problems that they will now not release patches for.
If 4.5.2 is getting security updates, then since 4.0 "support" is included with it...I'd have to think it would also get updated in the process. Okay sure, Microsoft can tend to be a big bag of dicks...but do you really think they'd push it to only updating half of an existing package?