Developer PSA: Support Ending for the .NET Framework 4, 4.5 and 4.5.1

[wraith808]

http://blogs.msdn.co...4-4-5-and-4-5-1.aspx

I don't know how I missed this!

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.

More at link.  I thought the versions that were affected... and unaffected... were interesting, and confusing!

[Renegade]

Thanks for the heads up.

[Stoic Joker]

Why would they need to support 4.0 directly? 4.5.1 gets upgraded to 4.5.2, and 4.5.2 includes 4.0 just like 3.5 includes 3.0 and 2.0. So they're not really orphaning it, their just bundling it in with the latest version to limit the number of updates that need to be futzed with.

[wraith808]

Why would they need to support 4.0 directly? 4.5.1 gets upgraded to 4.5.2, and 4.5.2 includes 4.0 just like 3.5 includes 3.0 and 2.0. So they're not really orphaning it, their just bundling it in with the latest version to limit the number of updates that need to be futzed with.

[ Invalid Attachment ]

-Stoic Joker (December 12, 2015, 07:53 AM)

Because of software and development.  If you target 4.0 in your applications, then you are using an unsupported version.  Much of our infrastructure in the company I work for is using 4.0.  Most of the software I have linked from the site also uses 4.0.  Unless I recompile it for 4.5 and re-release, it's unsupported.  Even if the assemblies for the versions are in the same place, they are not the same version, as you can see by the linked assemblies a build is targeting.

[Stoic Joker]

Um... Okay, but just because they're dropping support for a specific install version of a framework doesn't (appear to) mean it's no longer usable. It just means - or at least appears to mean - that you need to be running a supported version that includes it.

You may have one or more applications that are currently targeting a .NET Framework version that will no longer be supported. You can run those applications on a later .NET Framework version without targeting a new version

-the article you linked to

I would read that as meaning if you call MS for support on an issue with - an as installed version of - .NET4.0 they'll tell you that you will have to update it to v4.5.2 - which includes 4.0 - before they will help with anything. So if you're compiled to run 4.0, and have 4.5.2 installed (which includes 4.0) there shouldn't be any issues.



(Only tangentially related)
Now granted I just started playing with C#/.NET stuff in the last few years...so it's really not my thing. But it appears that you can target a project to multiple .NET versions:

By default, an app runs on the version of the .NET Framework that it was built for. If that version is not present and the app configuration file does not define supported versions, a .NET Framework initialization error may occur. In this case, the attempt to run the app will fail.

To define the specific versions on which your app runs, add one or more <supportedRuntime> elements to your app's configuration file. Each <supportedRuntime> element lists a supported version of the runtime, with the first specifying the most preferred version and the last specifying the least preferred version.

^From here: Version Compatibility in the .NET Framework

[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)

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.

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."

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)

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)

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)

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)

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.

[wraith808]

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?

-Stoic Joker (December 12, 2015, 03:26 PM)

That's just it.  If 4.0 support was just included and it just worked out of the box, I'd agree with you.  But it is only pre-supposed to be working.  They haven't tested everything- that's pretty evident from the post, and pretty self-evident as they can't test every bit of code out there.

Are there any breaking changes in .NET 4.5.2? Why do you include these changes?

There are a very small number of changes in .NET 4.5.2 that are not fully compatible with earlier .NET versions. We include these changes only when absolutely necessary in the interests of security, in order to comply with industry wide standards, or in order to correct a previous incompatibility within .NET. Additionally, there are a small number of changes included in .NET 4.5.2 that will only be enabled if you choose to recompile your application against .NET 4.5.2.

They're trying best-effort, and they're trying to minimize the perceived impact...

... but tell that to the boss when you're in the whatever percentage.

Check these two links:

https://msdn.microso...58358(v=vs.110).aspx

https://msdn.microso...61502(v=vs.110).aspx

Now, admittedly, most of this you can get around.  But you have to get around it.  Just letting MS autotarget?  That's a recipe for failure for someone.  And that someone may be you.

[Stoic Joker]

hehe Okay, so this isn't so much a directly technical issue as it is a tingling sensation ... I'm good with that. Experience has taught me to always abide by funny feelings, as they're frequently linked to subconscious reasons that haven't quite surfaced yet..

Because Murphy's Law dictates that you'll have an 85% chance of screwing up a 50/50.