Other Software > Developer's Corner
Developer PSA: Support Ending for the .NET Framework 4, 4.5 and 4.5.1
wraith808:
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. And there are changes between .NET versions. I know because I've had to go through this before, and the behaviour 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. 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. But what I'm really talking about is security problems that they will now now release patches for.
It's not a simple issue, and it's not necessarily a simple fix either.
TaoPhoenix:
"As previously announced, starting January 12, 2016 Microsoft will no longer provide security updates, technical support or hotfixes for .NET 4, 4.5, and 4.5.1 frameworks. All other framework versions, including 3.5, 4.5.2, 4.6 and 4.6.1, will be supported for the duration of their established lifecycle. The decision to end support for these versions will allow us to invest more resources towards improvements of the .NET Framework."
All of this wraps into some weirdness with my AdiIRC client new version, so I gotta keep my eye on this thread!
I expect I'll have to ask for tips in a lil' bit, I just don't have my grasp together on this yet what to ask.
wraith808:
"As previously announced, starting January 12, 2016 Microsoft will no longer provide security updates, technical support or hotfixes for .NET 4, 4.5, and 4.5.1 frameworks. All other framework versions, including 3.5, 4.5.2, 4.6 and 4.6.1, will be supported for the duration of their established lifecycle. The decision to end support for these versions will allow us to invest more resources towards improvements of the .NET Framework."
All of this wraps into some weirdness with my AdiIRC client new version, so I gotta keep my eye on this thread!
I expect I'll have to ask for tips in a lil' bit, I just don't have my grasp together on this yet what to ask.
-TaoPhoenix (December 12, 2015, 02:55 PM)
--- End quote ---
There is nothing you can do. Side-by-Side configuration just lets you run different versions. In our case at work, we have a legacy platform that we couldn't upgrade at the time, but a new platform that had to use assemblies for the older update. The Side-by-Side that Stoic linked to does exactly what it says. Allows you to run versions side-by-side, or in parallel. Even when configured, if your app targets the older version- it will use the older version. Things that target the newer version, use the newer. It does, however, let you specify versions of the framework that your application is compatible with. But, back to the article that Stoic linked- there's a minor blurb there, that shows what I am concerned about:
In practice, this compatibility can be broken by seemingly inconsequential changes in the .NET Framework and changes in programming techniques.
--- End quote ---
The only thing you can do is request that the makers of AdiIRC recompile it for 4.5.2 or 4.6.
And to further cloud the issue, I want to point out the verbiage they use and what it implies to me.
"All other framework versions, including 3.5, 4.5.2, 4.6 and 4.6.1, will be supported for the duration of their established lifecycle."
--- End quote ---
Why those versions? And how much savings in resources will that mean? It just doesn't add up. Why break the lifecycle rules now? But in any case, this was just a PSA, as I'd not seen talk about it anywhere, and missed the original announcement, and thought others might have also.
Stoic Joker:
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.-wraith808 (December 12, 2015, 01:55 PM)
--- End quote ---
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.-wraith808 (December 12, 2015, 01:55 PM)
--- End quote ---
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.-wraith808 (December 12, 2015, 01:55 PM)
--- End quote ---
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.-wraith808 (December 12, 2015, 01:55 PM)
--- End quote ---
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?
TaoPhoenix:
Well good stuff Wraith and Joker, that's why I started out vague,
I have like 8 things to test before I can ask a coherent question, not the least 1 of 8 or whatever is my comp itself is starting to go and I haven't rebooted for weeks. (I just have too much important stuff open right now!). The two processes could have the same name and one is open right now, who knows.
At least when I try to ask a question, I try hard sometimes to do as much homework first as I can so the question comes out better.
So all I know is I have to get past Ludum Dare first, then some health ins stuff (kick it back to their court then I get to wait aka breathing space while stuff wanders around on their side of the cyber-space tennis court).
Meanwhile the dev / team looks like he tries pretty hard, he's issued .x version updates like 4 days apart, and the new copy came out a month ago, so if in case he missed something like this and I "prove it" with you guys, I'd wager he'd fix it and recompile and he has no qualms about "oops i goofed" and that's awesome he doesn't try to bury stuff in squirrelly language.
I just won't have anything coherent to ask for a couple of weeks. :(
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version