[release/6.0] Fix pinned assembly version 6.0 #84357
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/6.0-staging 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
| @@ -7,7 +7,7 @@ | |||
| <IsPackable>true</IsPackable> | |||
| <!-- If you enable GeneratePackageOnBuild for this package and bump ServicingVersion, make sure to also bump ServicingVersion in Microsoft.Windows.Compatibility.csproj once for the next release. --> | |||
There was a problem hiding this comment.
Both OOB packages that are getting built need Microsoft.Windows.Compatibility to be built as well.
rbhanda
added
Servicing-approved
|
All failures are known and tracked. |
Backport of #84079 to release/6.0-staging
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.