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?
Related
I am converting a .NET Framework 4.7.1 class library to .NET Standard 2.0.
The library consumes a number of Nuget packages, all of which are available for both .NET Framework and .NET Standard and these packages include the WindowsAzure.Storage SDK.
The original .NET Framework class library compiles and runs correctly, but the .NET Standard library fails to compile, due to missing APIs (and some different method signatures) on the WindowsAzure.Storage SDK.
For example, CloudBlockBlob has a DeleteIfExists method in .NET Framework but not in .NET Standard.
The API documentation lists this method (and all the others that are broken in .NET Standard) but doesn't appear to mention any version differences between target frameworks. Did I miss something relevant here?
Is it normal that some .NET Standard Nuget packages have gaps in their APIs?
Is there a solution or a workaround for this (apart from re-writing the code that consumes these APIs)?
Thanks, in advance.
As per Peter Bons mentioned, In the nuget package WindowsAzure.Storage, there are only task based methods, so DeleteIfExistsAsync for .net core / .net standard.
Please use the new nuget package for azure storage. For blob storage, you can install Microsoft.Azure.Storage.Blob, version 9.4.0 or above, which does support sync / async methods.
The change log is here:
And here is a simple test with .net standard project with Microsoft.Azure.Storage.Blob, version 9.4.0 or above installed. Both sync / async methods are there.
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.
We are using NotificationHubs version 1.0.9 with .NetCore 2.0 and .Net Framework 4.7.
At compile time, we get this warning:
"Package Microsoft.Azure.NOtificationHubs 1.0.9 was restored using '.NETFramework, version=4.6.1' instead of the project target framework '.NETCoreApp, version=2.0. this package may not be fully compatible with your project."
Everything is still built, but at runtime when this call is invoked:
RegistrationDescription hubRegistration = await hubClient.CreateAppleNativeRegistrationAsync(device.DeviceToken); //hubClient is NotificationHubClient
We get this error:
Has anyone encountered this before and have any idea how to fix it?
At compile time, see this warning: "Package Microsoft.Azure.NOtificationHubs 1.0.9 was restored using '.NETFramework, version=4.6.1' instead of the project target framework '.NETCoreApp, version=2.0. this package may not be fully compatible with your project."
The Microsoft.Azure.NotificationHubs package requires .Net Framework 4.5 Full Profile. And here is a feedback Microsoft.Azure.NotificationHubs add support for .NET CORE.
AFAIK, if you create the ASP.NET Core Web Application with the target framework at .NetCore 1.0 or .NetCore 1.1, you could edit your *.csproj and change the TargetFramework to net461, then you could install and use Microsoft.Azure.NotificationHubs 1.0.9.
While for .NetCore 2.0 MVC, after you create the project, it would reference the Microsoft.AspNetCore.All 2.0.0, and this package supports netcoreapp2.0. I assumed that you could leverage Notification Hubs REST APIs and follow the git sample azure-notifications Send REST to access your notification hub for a workaround.
A preview version of a .NET Standard compatible NuGet is now available. It will allow using Notification Hubs with .NET core.
According to a Microsoft Product Manager a new version of the .NET SDK supporting .NET Core will be deployed very soon.
cf this question
But no mention on Feedback Microsoft site. I would recommend to vote for this feature
I have an AzureAD registered Web API working correctly. I am able to acquire the access token by means of AcquireTokenAsync. No problems there. However, no I need to downgrade my rest client library to .net 3.5. I am not being able to use ADAL in .net 3.5. AcquireTokenAsync returns a Task, which is not supported in 3.5. I have read in some tutorials that there is a non async verstion of the method (AcquireToken) here. But I just can't access that method. Also, when I try to install that specific version of ADAL(2.19.208020213) I get a Nuget error saying there is no version supported to .Net 3.5
What am I doing wrong?
UPDATE
I am trying to find out which version of ADAL targets .Net 3.5 so I can install it in my project.
UPDATE 2
If ADAL is not supported in .Net 3.5, what are my options to obtain authorization token from Azure AD in .net 3.5?
The library only supports 4.5 because async support was added in that .net release. You may need to dig back to very old versions of the library to get older .net sdk to work. But you would lose significant big fixes and features.
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.