[release/7.0] Fix pinned assembly version 7.0 #84355
Conversation
… compatibility. The incremental package servicing infrastructure didn't check if the assembly version is pinned and changed it during servicing. As an example, System.Speech pins its assembly version to 4.0.0.0 but that version gets overwritten during servicing. I.e. for .NET 7 the version would then change to "7.0.0.$(ServicingVersion)" which is incorrect. Please find the full list of impacted assemblies below: - System.ComponentModel.Composition - System.DirectoryServices - System.DirectoryServices.AccountManagement - System.DirectoryServices.Protocols - System.Management - System.Reflection.Context - System.Runtime.Caching - System.Speech For System.DirectoryServices.Protocols and System.Management we'll only pin the version for the .NETStandard assembly since those previously shipped the newer versions in servicing.
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsBackport of #84079 to release/7.0 Customer ImpactCustomer using 6.0.1 and 7.0.1 package of System.Management faces assembly load errors when running on .NETFramework, or all frameworks when upgrading from these packages to a non-servicing release (7.0.0, 8.0.0-preview). Customer on .NETFramework who consumes a NETStandard library using either package will see build warnings like: Root cause is that we accidentally increased the assembly versions of these libraries (and 5 others that luckily haven't shipped) from 4.0.0.0 to 6|7.0.0.n during our servicing builds. TestingBuild / diff all assembly versions. Package testing. TODO: Targeted manual regression tests along upgrade path and in cross-framework consumption scenario. RiskLow, the change is isolated to the 8 libraries that pin their assembly versions to enable .NETFramework support. We further reduced risk by only allowing the higher versions of the 2 libraries that already shipped. To reduce the number of people that need to update to get a fix, we let those 2 libraries stay at the higher version for .NET 7. In .NET 8 we made all 8 libraries reduce their use of this pinned assembly version so-as to make them less special.
|
ericstj
changed the title
rbhanda
added
Servicing-approved
|
When will a new version of System.DirectoryServices.Protocols ship? Referencing versioning 7.0.0.0 still causes Microsoft.AspNetCore.Authentication.Negotiate to break.
|
|
@stcpottdav Probably mid next month with the regular release, but the issue with this combination you posted is not really System.DirectoryServices.Protocols anymore. Microsoft.AspNetCore.Authentication.Negotiate 6.0.16 references the "broken" assembly version 6.0.0.1 of System.DirectoryServices.Protocols, which is now fixed to be 4.0.0.0 again in the new 7.0.0 package version. If you need to use aspnetcore 6 because you're targeting net6 for example, you will still need to use the old System.DirectoryServices.Protocols package version 6.0.1, which still contains the assembly version 6.0.0.1, as it's requested by the aspnetcore package you're referencing. You can see that in the Nuget Package Explorer for example:
I don't think direct links are a thing, just navigate to the dll. |
|
Thanks for the response. The issue is that CoreWCF references System.DriectoryServices.Proctocols 7, so users on .NET 6 are stuck on version 1.1. I.E. Our application actually does target 6.0.1 internally but targeting CoreWcf 1.3.2 breaks the app. Another workaround may be using the IIS authentication scheme instead of Negotiate. |
Backport of #84079 to release/7.0
Customer Impact
Customer using 6.0.1 and 7.0.1 package of System.Management faces assembly load errors when running on .NETFramework, or all frameworks when upgrading from these packages to a non-servicing release (7.0.0, 8.0.0-preview).
Customer using 6.0.1 System.DirectoryServices.Protocols package faces assembly load errors when running on .NETFramework, or all frameworks when upgrading from this packages to a non-servicing release (7.0.0, 8.0.0-preview).
Customer on .NETFramework who consumes a NETStandard library using either package will see build warnings like:
Root cause is that we accidentally increased the assembly versions of these libraries (and 5 others that luckily haven't shipped) from 4.0.0.0 to 6|7.0.0.n during our servicing builds.
Testing
Build / diff all assembly versions. Package testing. TODO: Targeted manual regression tests along upgrade path and in cross-framework consumption scenario.
7.0 diff: https://gist.github.com/ericstj/5e914be725066df9824fd1e3fca12c08
6.0 diff: https://gist.github.com/ericstj/83579179870f159bdbbe0c923f457526
Risk
Low, the change is isolated to the 8 libraries that pin their assembly versions to enable .NETFramework support. We further reduced risk by only allowing the higher versions of the 2 libraries that already shipped. To reduce the number of people that need to update to get a fix, we let those 2 libraries stay at the higher version for .NET 7. In .NET 8 we made all 8 libraries reduce their use of this pinned assembly version so-as to make them less special.