I have this issue in which I'm currently targeting .NET Framework 4.7.2 in my solution but the Azure Web App Service only supports up to .NET Framework 4.7.1. So, my question is this: As long as I only use 4.7.1 features, should it work without issue on the Azure Web App Service (which only supports up to 4.7.1) even though I'm targeting 4.7.2? Are the .NET Frameworks backwards compatible? So far, I haven't seen any issues. I just want to make sure there will be no future complications. Ideally, I would like to keep targeting 4.7.2 so that I can start using the 4.7.2 features once it becomes available on Azure Web App Service.
The .NET Framework 4.7.2 builds on previous versions of the .NET Framework 4.x by adding many new fixes and several new features while remaining a very stable product.
The .NET Framework 4.7.2 is included with the Windows 10 April 2018 Update
The .NET Framework 4.7.2 can be used to run applications built for the .NET Framework 4.0 through 4.7.1.
Azure App Service now supports 4.7.2
I think that you did a good thing in upgrading and targeting .NET Framework 4.7.2 ; I also have an Azure App Service and upgraded it to 4.7.2 and it is running very well. As said before, it brings updates and fixes, and it is backward compatible on almost all cases.
Note that the recommended is that the target machine have a .Net version Equal or Greater of the of the .NET Framework 4.x than your compiled version.
See:
https://learn.microsoft.com/en-us/dotnet/framework/whats-new/index#v472
https://learn.microsoft.com/en-us/dotnet/framework/install/on-windows-10
#TheDude, you cannot build an app on 4.7.2 and hope to run it on lower version like 4.7.1. At runtime the target framework version check will fail as it will find the Framework version (4.7.2) as missing.
The other way round (i.e. target 4.7.1 and run on 4.7.2) is fine as the higher versions are backwards compatible.
Related
I keep getting this error when I try to run the pipelines for my azure backend functions:
[error]C:\Users\VssAdministrator.nuget\packages\microsoft.net.sdk.functions\1.0.27\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(41,5): Error : It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
It's a pretty old program, but yesterday was the first time that the build has failed and I don't know how to fix it. It happens both in the develop and main branch so I'm guessing it's a change from Azure.
As documented in this GitHub issue .NET Core 2.1 has been removed from all build agent images.
Possible impact
If your project depends on a pre-installed .Net 2.1 it can be broken.
You can try to use the setup dotnet task to explicitly install .NET Core 2.1.
- uses: actions/setup-dotnet#v1
with:
dotnet-version: '2.1.x'
Please be advised .NET Core 2.1 has been out of support since August 21, 2021 (see .NET and .NET Core Support Policy). An upgrade to a currently supported version like .NET Core 3.1 or higher should not be a lot of work and is well worth the effort.
According to Support and Retirement Information for the Azure SDK for .NET and APIs, SDK 2.6 introduced support for .NET 4.6. None of the listed SDKs explicitly mention 4.6.2 though the sister article Install .NET on a Cloud Service Role includes an installation script that explicitly installs .NET 4.6.2, implying that it is supported for web/worker roles.
When I attempted to upgrade my solution from .NET 4.5.1 (using Azure SDK 2.8) to .NET 4.6.2, I also modified my RoleProperties.txt file which included the following lines:
TargetFrameWorkVersion=v4.5.1
RoleTargetFramework=v4.5.1
to
TargetFrameWorkVersion=v4.6.2
RoleTargetFramework=v4.6.2
which resulted in the following error after calling cspack.exe:
Unsupported .Net Framework v4.6.2
I tried changing the 4.6.2 to simply 4.6 and that similarly failed.
So my questions are:
How do you correctly target .NET 4.6.2 using cspack.exe?
Is it necessary to set those properties to 4.6* or is it safe to leave them at 4.5.1 since cspack.exe doesn't complain?
The documentation about Linux hosting only mentions mono. Can the new .net core and asp.net core (DNX) also be used?
ServiceStack now supports running on .NET Core from October 20, 2016 v4.5.2 Release.
Nearly all of ServiceStack’s features are now available across 21 of our most popular NuGet packages, inc. OrmLite support for SQL Server, PostgreSQL and Sqlite. We’ve been able to achieve excellent integration and code-reuse where your ServiceStack AppHost can be registered as a .NET Core module and most of your Service Implementation using ServiceStack libraries remains unchanged.
We’ve ported a number of existing Live Demos to .NET Core providing example projects so you can easily compare .NET 4.5 ServiceStack code-bases with what it looks like in .NET Core at:
https://github.com/NetCoreApps/LiveDemos
All .NET Core Live Demos are running on Linux / Docker using AWS ECS Container Service.
We’re maintaining .NET Core packages isolated from the Main NuGet packages separated with a .Core suffix until we’re satisfied .NET Core has been battle-tested in the wild which will enable us to make frequent releases outside of the main .NET 4.5 release cycle.
Please see the full v4.5.2 Release Notes for details on running ServiceStack on .NET Core, its integration story and the different conventions in .NET Core.
I use Azure to host a cloud service, and I updated my code to target the .NET 4.5.2 Framework. When I published it, things went kablooey:
The 'targetFramework' attribute in the element of the Web.config file is used only to target version 4.0 and later of the .NET Framework (for example, ''). The 'targetFramework' attribute currently references a version that is later than the installed version of the .NET Framework. Specify a valid target version of the .NET Framework, or install the required version of the .NET Framework.
The yellow screen of death threw up here:
compilation strict="false" explicit="true" targetFramework="4.5.2"
So I'm confused here because I don't NEED to target 4.5.2 for any special features in my code, but 4.5 seems "old". Am I using cloud services wrong here? Is there a problem for me to continue using 4.5? OR should I go through some steps to have 4.5.2 available when I publish my code?
The reason you're getting this error is because .Net Framework 4.5.2 is not installed on your Cloud Service Virtual Machines by default. This is something that Microsoft is planning on doing very shortly (based on the email sent out by Microsoft earlier this week).
From that email:
On August 7, 2014, Microsoft announced that support will end for .NET
Framework 4, 4.5, and 4.5.1 on January 12, 2016. It is recommended
that customers and developers complete the in-place update to .NET
Framework 4.5.2 by January 12, 2016 to continue receiving technical
support and security updates. Visit Microsoft .NET Framework Support
Lifecycle Policy for more details. On October 27, we announced
that, Azure will update the .NET Framework in Windows Azure Guest
operating system (Guest OS) family 2.x, 3.x and 4.x to .NET Framework
4.5.2 in the upcoming November Guest OS Release. Since then, we have received customers’ feedback to postpone the automatic update to an OS
release with .NET 4.5.2 and provide an image with .NET 4.5.2 for test
validation.
To better accommodate customers’ requirements and provide a smooth
upgrade to .NET 4.5.2, Azure will update the .NET Framework in Windows
Azure Guest operating system (Guest OS) family 2.x, 3.x and 4.x to
.NET Framework 4.5.2 in the January 2016 Guest OS Release. Cloud
services running on Guest OS family 2.x, 3.x and 4.x with automatic
updates enabled will be updated to the January 2016 Guest OS with .NET
Framework 4.5.2. In November, the .NET Framework installed in the
default OS will not be changed. In order to help customers validate
their cloud service with .NET 4.5.2, Azure will provide a second set
of November OS Versions 201511-02 for with .NET 4.5.2 for manual
deployment.
To manually install .Net Framework 4.5.2 in your Cloud Service, you may find this link helpful: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-install-dotnet.
In case it helps anyone. I had the same issue and my fix was to update the OS from Windows Server 2012 to the latest OS (Currently Windows Server 2016) for the cloud service which fixed the problem.
I have a WPF application that targets framework v4.0 and uses async BCL. It seems that installing only .net framework v4.0 on fresh W7 OS is not enough, since as it seems, there was a bug which was corrected with later update. For example, installing update v4.0.3 solves the problem with using async BCL on framework v4.0.
My concern is this: On my developer machine (W8.1) I do not have this update installed (at least it is not registered in windows registry, nor under the windows updates). Still, my application is working just fine, which means that the update is somehow installed through some other method.
The question: how can I know that application that uses async BCL will work correctly on client's OS? Currently, when I install the application (wix 3.8), I check if .net 4.0 is installed, and I check if KB2600211 (4.0.3) is installed (by searching adequate registry keys). If not, I install them, but I am wondering if searching for KB2600211 is the right approach? Is there some other way to make sure that app will work correctly?
On your Windows 8.1 you have .NET 4.5.1 which is an in-place update for .NET 4.5 which is an in-place update for .NET 4.0. That means you no longer have plain .NET 4.0 (.NET 4.0.x, for that matter).
I recommend you to always test on the target environments. It can be as simple as having a VM.