Dotnet: ARE YOU KIDDING ME????

Created on 25 Jun 2020  Â·  8Comments  Â·  Source: microsoft/dotnet

JUST RECEIVED YOUR EMAIL ABOUT .NET 4.8 UPGRADE DUE BY JULY 14 2020. WE HAVE OTHER THINGS TO DO THAN TO REACT TO A MANDATE IN BASICALLY THREE WEEKS. THIS REALLY PUTS US BETWEEN A ROCK AND A HARD PLACE. THIS KIND OF CRAP MAKES ME WANT TO TAKE OUR ENTIRE ENVIRONMENT ELSE WHERE. THANKS FOR THE 3 WEEKS HEADS UP.

DOUG SROFE
CIO
EAGLE PHARMACY

.NET Framework

Most helpful comment

@SA-support

According to these articles (and by checking it manually), you can see multiple versions of .NET Framework are installed on the VM. What do you mean with "we only support one version of .NET Framework"?

This is how you determine the current framework installed in Windows. In the stack overflow answers that you link, they show the reference assemblies folder, which is used when compiling code targeting those versions listed. That is, those version folders you see there are part of the SDK not the runtime specifically.

There can only be one .NET 4.x runtime installed at a time.

A stack answer I wrote re 4.8 App Service migration:

Assuming your apps are already targeting a supported version of .NET (currently >= 4.5.2), then retargeting your apps to 4.8 is not compulsory. Particularly if you do not plan to take advantage of any new features. See .NET docs:

4.x versions of the .NET Framework can be used to run applications built for the .NET Framework 4.0 through that version. For example, .NET Framework 4.7 can be used to run applications built for the .NET Framework 4.0 through 4.7. The latest version (the .NET Framework 4.8) can be used to run applications built with all versions of the .NET Framework starting with 4.0.

As a minimum, you could run some regression tests against your app running on 4.8 before going live. How much testing it takes to gain confidence, and the chances of breaking changes, depends largely on what version you are currently targeting.

Ideally however, if you are in a position to retarget, build and deploy for 4.8, then a lot of unexpected behaviour can be caught even earlier by the compiler. Note that there are sometimes changes that require code changes and again, the likelihood depends very much on what you target at present.

To get an idea of what work you might need to do in your code:

EDIT: As of 26.6.2020 I am not aware of any plans to accommodate testing apps running in an App Service on 4.8 before the upgrade date, which means you will only be able to test on 4.8 locally.

All 8 comments

I assume you are referring to Azure App Servicing moving to .NET Framework 4.8, on July 14th. The following mail was sent out to Azure App Service users (screenshot below) to explain what is happening. The .NET Framework 4.8 Availability on App Service announcement also describe those plans and changes.

image

As you may know, we only support one version of .NET Framework as part of a Windows installation. I am assuming that App Service team is upgrading all of their servers to .NET Framework 4.8. This is necessary, in order to allow other users to use .NET Framework 4.8 APIs and features.

Existing .NET Framework applications should run correctly on top of this new version without changes. .NET Framework 4.8 was released over a year ago. It is now the most heavily used version of .NET Framework, and we haven't heard much about migration challenges. We expect that your experience will be similarly straightforward.

In terms of what you can do, we recommend you test your application with .NET Framework 4.8 on you local machines. Assuming that works without issue, then one can reasonably expect that you will not notice the update on July 14th. This is the same guidance as you see in the email above.

Does that explanation help? Thanks.

@richlander

https://stackoverflow.com/questions/24144331/what-versions-of-net-are-supported-on-azure-web-sites
https://stackoverflow.com/questions/51433805/does-windows-azure-app-service-support-net-framework-4-7-2

According to these articles (and by checking it manually), you can see multiple versions of .NET Framework are installed on the VM. What do you mean with "we only support one version of .NET Framework"?

Does it affect a WebJob that is being published using .NET Framework 4.6.2 (according to the project settings), will it automatically use the installed 4.6.2 or is it currently already using 4.7 (as that is the only framework being visible in the configuration of the Web App)?
Will such a WebJob be forced to use 4.8 after this update?

On my local dev machine, I noticed (https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed) only 4.8 is installed, so that maybe implies all our software is already using .NET Framework 4.8 when I am running them on my local machine.

How about a CMS (like DotNetNuke) that is being installed on a Web App using FTP?
I assume it was built using a specific .NET Framework at some point, will it always use the default .NET Framework version visible at the configuration of the Web App (4.8)?
Or will these .NET Framework projects always use the framework selected at the project settings (Target Framework) at the time of build/deployment? Even when you see 4.7 (or 4.8) selected at the configuration of the Web App?

Testing many systems, WebJobs and more, possibly fixing them and redeployment (and more testing) during the summer holiday, with a 3-week notice is sort of impossible...

@SA-support

According to these articles (and by checking it manually), you can see multiple versions of .NET Framework are installed on the VM. What do you mean with "we only support one version of .NET Framework"?

This is how you determine the current framework installed in Windows. In the stack overflow answers that you link, they show the reference assemblies folder, which is used when compiling code targeting those versions listed. That is, those version folders you see there are part of the SDK not the runtime specifically.

There can only be one .NET 4.x runtime installed at a time.

A stack answer I wrote re 4.8 App Service migration:

Assuming your apps are already targeting a supported version of .NET (currently >= 4.5.2), then retargeting your apps to 4.8 is not compulsory. Particularly if you do not plan to take advantage of any new features. See .NET docs:

4.x versions of the .NET Framework can be used to run applications built for the .NET Framework 4.0 through that version. For example, .NET Framework 4.7 can be used to run applications built for the .NET Framework 4.0 through 4.7. The latest version (the .NET Framework 4.8) can be used to run applications built with all versions of the .NET Framework starting with 4.0.

As a minimum, you could run some regression tests against your app running on 4.8 before going live. How much testing it takes to gain confidence, and the chances of breaking changes, depends largely on what version you are currently targeting.

Ideally however, if you are in a position to retarget, build and deploy for 4.8, then a lot of unexpected behaviour can be caught even earlier by the compiler. Note that there are sometimes changes that require code changes and again, the likelihood depends very much on what you target at present.

To get an idea of what work you might need to do in your code:

EDIT: As of 26.6.2020 I am not aware of any plans to accommodate testing apps running in an App Service on 4.8 before the upgrade date, which means you will only be able to test on 4.8 locally.

How we interpreted the notification we received is that we had to upgrade all of our .net framework applications to 4.8 by the specified date. If you are telling me that 4.8 is going to be installed but the other versions remain and that we don’t have to upgrade, then that is a different story. The notification came across as a mandate to convert in 3 weeks.

This is the notification we received.

Test your Azure App Service apps using .NET Framework 4.8 by July 14, 2020

You're receiving this email because you're running a Windows application on App Service.

To improve Azure App Service, we're updating the platform to use .NET Framework 4.8https://github.com/microsoft/dotnet/blob/master/releases/net48/README.md. The update will begin on July 14, 2020, and your apps will be automatically updated by September 15, 2020.

When the update begins, we'll share our progress on GitHubhttps://aka.ms/dotnetframeworkupdates.

Recommended action

To ensure that your App Service apps will run smoothly with the updated platform, test them locallyhttps://github.com/jeffwmartinez/appservicedotnetframework.github.io#net-framework-48-is-coming-to-app-service using .NET Framework 4.8 by July 14, 2020.
If you have questions, please contact ushttps://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview.

Thanks,

Douglas Srofe
Chief Information Officer
[cid:[email protected]]

350 Eagles Landing Drive
Lakeland, FL 33810
t: +1 863-825-4181
m: +1 813-857-4115
e: [email protected]dsrofe@eaglesfp.com

www.eaglesfp.comhttp://www.eaglesfp.com/
[cid:[email protected]] https://www.facebook.com/Eagle-SFP-1133509183492377/?modal=admin_todo_tour [cid:[email protected]] https://www.linkedin.com/company/eaglesfp/ [cid:[email protected]] https://twitter.com/Eagle_sfp

From: benhall_io notifications@github.com
Sent: Friday, June 26, 2020 7:03 AM
To: microsoft/dotnet dotnet@noreply.github.com
Cc: Srofe, Doug dsrofe@pharmaservices-us.com; Author author@noreply.github.com
Subject: Re: [microsoft/dotnet] ARE YOU KIDDING ME???? (#1223)

According to these articles (and by checking it manually), you can see multiple versions of .NET Framework are installed on the VM. What do you mean with "we only support one version of .NET Framework"?

This is how you determine the current framework installed in Windowshttps://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed. In the stack overflow answers that you link, they show the reference assemblieshttps://docs.microsoft.com/en-us/dotnet/standard/assembly/reference-assemblies folder, which is used when compiling code targeting those versions listed. That is, those version folders you see there are part of the SDK not the runtime specifically.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/dotnet/issues/1223#issuecomment-650120899, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK3V72I2NKQ5YNWZ67VSVQ3RYR57LANCNFSM4OIHYFLQ.

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Hi folks,
I have a couple of simple legacy sites currently set to .NET framework v3.5 on the app service general stack settings. What does this update mean for these sites? Will this setting still be available after these updates?

Hi folks,
I have a couple of simple legacy sites currently set to .NET framework v3.5 on the app service general stack settings. What does this update mean for these sites? Will this setting still be available after these updates?

.NET 3.5 and .NET 4.8 co-exist, with new versions of .NET 4.x being in-place updates to previous updates for .NET 4.x, while .NET 3.5 is a completely independent, side by side stack. So if your application is running on .NET 3.5 today there should be no impact to the .NET 3.5 stack on account of the rollout of .NET 4.8.

Great, thanks @jamshedd !

It's important to note that you can't just update to 4.8 from 3.5. There's at least one major breaking change when you upgrade to .NET 4.5+, and that is the change to how closures operate. (lamda expressions) https://stackoverflow.com/questions/8649337/is-access-to-modified-closure-resolved-by-comprehension-syntax

Was this page helpful?
0 / 5 - 0 ratings