Closed davidebbo closed 6 years ago
So to be clear, if we install 4.7.1 and build an app targeting 4.7.1, we will NOT be able to successfully deploy that to Azure (as a web app or web job) until sometime in December?
That's correct. But note that there is no reason to target 4.7.1 unless you need a specific feature that it adds support for.
@davidebbo When exactly it will be deployed in December ? First week or last week ?
It's a gradual deployment, so it's hard to tell when a specific app will get it.
We are targeting 4.7.1 that references .net standard 2.0 libraries. We are getting error "Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified. in 4.7.1". The build doesn't include .net standard libraries as 4.7.1 is supposed to include them. What we can we do in the meantime?
@rsaa Target 4.7 in the meantime. It still supports .NET Standard 2.0 via additional assemblies that are included in your build.
@davidebbo Will all new app service plans created after the rollout begins Dec 4th have 4.7.1 and Windows Server 2016?
@JeremyWeir @davidebbo Good question. Also I received the email about Windows Server 2016 but I don't see anything on the announcements repo about it.
@JeremyWeir the creation time of an App Service Plan has no bearing on when it gets this upgrade. Upgrades are rolled our progressively through all the scale units, which is the determining factor in when a given Plan gets it, regardless of its creation time.
The 4.7.1 upgrade and 2016 upgrade are tied, so both will come together. I just opened https://github.com/Azure/app-service-announcements/issues/63 to complement the email that was sent.
@davidebbo It is expected that deployment process is going to be completed in December, right ?
@YakupIpek it may go into early January for some scale units, depending on how things go for the early ones.
How can we check for our concrete App Service Plan, when and if we are already have upgrade?
@hkasawa see the FAQ in https://github.com/Azure/app-service-announcements/issues/63, under "How can I check if my app has been updated?". 2012 has 4.7, and 2016 has 4.7.1.
Is there any way to deploy a 4.7.1 website to an app service where this update has not yet been deployed?
@shaulbehr afaik only if you downgrade to 4.7
Bah. But thanks for clarifying.
@davidebbo if the app service for North Europe says it's already 2016, is it safe for me to start migration to 4.7.1? Is there a chance for region's OS to be rolled back to 2012 (given that entire migration process is planned to be completed by the end of Jan) or should I just wait until Feb?
Thank you!
@snekbaev yes, it is safe to assume that if your app in on 2016 / 4.7.1, it will not be rolled back to the older bits.
@davidebbo Unfortunately .net 4.7.1 version is not installed despite os is pointing to Windows Server 2016 on North Europe region. Deployment gives error below error.
\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1097,5): warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.7.1" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
I can also verify that 4.7.1 not installed by following instructions here https://blogs.msdn.microsoft.com/waws/2016/11/02/how-to-determine-the-installed-net-version-in-azure-app-services/
Anyone knows another region where .net 4.7.1 installed ?
didn't try deploying yet, just checked the file system:
My sites in US East are all on 2016 (spanning 3 VMs/subscriptions), but I'm not seeing 4.7.1 installed either.
4.7.1 should definitely be there. The folder you are looking at only reflects the presence of the SDK, and that is indeed something that needs to be added later. But that is not needed when deploying via VS or VSTS build server. It's only needed for Kudu.
Use the registry approach instead of the folder approach from the article above to determine the presence of the framework. That article confuses framework and SDK.
Using the registry method gives me 4.7.02558
for the version and 461310
for the release. Right now my sites are deploying via kudu so even if 4.7.1 is installed I can't use it until the SDK is available.
Yep, this is something we need to do. Sorry that the announcement was unclear on that point. We'll get to the SDK in January.
@davidebbo Its quite unclear if I should be able to build a v4.7.1 application in VSTS build or not. But I get this error when building Hosted 2017.
2018-01-05T09:04:31.4583559Z ##[error]C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1098,5): Error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.7.1" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
I really need this to work because of a netstandard nuget package that was supposed to go to our new .net core apps but also to our older apps that have not yet been moved to core.
If this is not working right now could you give us a date on when it will be or a link to where that information will pop up when it will?
Ok... for others that get this error you should double check if you get this warning below in the build. I really really thought I had selected Hosted VS2017 build but I seem to have been wrong.
[warning]Visual Studio version '15.0' not found. Falling back to version '14.0'.
You need to set your default Agent to Hosted VS2017 like done here.
There are 3 distinct things here:
Anyway, closing this one since deployment is complete.
@davidebbo I'm seeing D:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.1 Tools
showing for all of my sites now (some have a date of 2/6 and others 2/7). Does this mean I'm able to target & build .net 4.7.1 on these sites now?
@xt0rted yes, that's the expectation. /cc @watashiSHUN who is the expert here.
Is there any reason why, after switching from "Hosted" to "Hosted VS2017" my builds are now taking 3.3 minutes, when they usually took less than a 100 seconds?
@morphx666 I think you are referring to VSTS build agents, which is not related to this discussion.
I apologize - I was redirected here from a different thread and didn't take the time to read what this was all about.
@davidebbo In Deployment of .NET 4.7.1 to Azure App Service you said "The deployment is complete.".
So is .NET 4.7.1 available for app services? Currently I cannot select .NET 4.7.1 in app settings at Azure
@dalibor983 You can only choose between 4.x and 3.5 because they are different runtimes. 4.7.1 has been available on all app services since last month. But I agree that it is confusing. I wish they would rename that drop-down value in the portal to "4.x"
@dalibor983 @paulirwin I agree that the Portal display is a bit confusing. But indeed, it is 4.7.1 everywhere now.
Discussion thread for https://github.com/Azure/app-service-announcements/issues/51