Move to .NET SDK 9.0.300

Rx.NET/Source/src/.editorconfig → Rx.NET/Source/.editorconfig

@@ -34,7 +34,18 @@
 # reported as unnecessary on ObservableEx, but it is, so we've squelched it.
 # IL2060 is considered unnecessary on targets that don't support trimming, but we don't want to wrap every
 # single one in a conditional, so we also suppress warnings about unnecessary suppressions on those.
-dotnet_remove_unnecessary_suppression_exclusions = CA1704,CA1711,IL2060
+#
+# dotnet_remove_unnecessary_suppression_exclusions = CA1704,CA1711,IL2060
+#
+# Since moving to .NET SDK 9.0, we now get a lot more of these inexplicable IDE0079 warnings, where
+# if we remove the suppression that it complains about, we immediately get the warning that the suppression
+# is there to prevent. As far as I can tell, every suppression now causes a spurious IDE0079, so we
+# just have to disable IDE0079. Presumably there's something odd about this codebase that is confusing
+# the IDE0079 diagnostic - it can't be completely broken for everyone, because someone would have
+# noticed. I guess this may be related to the curse placed on this codebase by The Great Unification,
+# and in particular the corresponding requirement for putting a uap10.0.xxxx TFM on packages that
+# really shouldn't have them.
+dotnet_diagnostic.IDE0079.severity = silent
 
 
 # Prevent IDE1006 (Naming rule violation) errors for non-public fields.
@@ -68,3 +79,5 @@ dotnet_naming_symbols.protected_field_symbols.applicable_accessibilities = prote
 dotnet_naming_rule.protected_instance_fields_must_be_camel_cased_underscore_prefix.symbols  = protected_field_symbols
 dotnet_naming_rule.protected_instance_fields_must_be_camel_cased_underscore_prefix.style    = camel_case_and_prefix_with_underscore_style
 dotnet_naming_rule.protected_instance_fields_must_be_camel_cased_underscore_prefix.severity = none
+
+dotnet_style_require_accessibility_modifiers = for_non_interface_members

Rx.NET/Source/Directory.build.props

@@ -39,7 +39,7 @@
     -->
     <PackageReference
       Include="Nerdbank.GitVersioning"
-      Version="3.6.128"
+      Version="3.6.143"
       PrivateAssets="all"
       Condition="$(ProjectName) != 'Tests.System.Reactive.Uwp.DeviceRunner'" />
   </ItemGroup>
@@ -52,6 +52,27 @@
     <PackageReference Include="coverlet.collector" Version="3.2.0" />
   </ItemGroup>
 
+
+  <PropertyGroup Condition="'$(TargetFramework)'=='uap10.0.18362'">
+    <!--
+    See 0003-uap-targets.md ADR in documentation for the reasons behind these settings.
+    -->
+    <NoStdLib>True</NoStdLib>
+
+    <TargetPlatformMinVersion>10.0.18362</TargetPlatformMinVersion>
+    <TargetPlatformVersion>10.0.18362.0</TargetPlatformVersion>
+
+    <TargetPlatformIdentifier>UAP</TargetPlatformIdentifier>
+    <TargetFrameworkMoniker>.NETCore,Version=v5.0</TargetFrameworkMoniker>
+    <TargetFrameworkIdentifier>.NETCore</TargetFrameworkIdentifier>
+    <TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
+    <NugetTargetMoniker>UAP,Version=v10.0</NugetTargetMoniker>
+
+    <DefineConstants>$(DefineConstants);WINDOWS_UWP</DefineConstants>
+
+  </PropertyGroup>
+
+
   <PropertyGroup>
     <AnalysisLevelDesign>7.0-default</AnalysisLevelDesign>
     <AnalysisLevelNaming>7.0-all</AnalysisLevelNaming>
@@ -72,9 +93,16 @@
                 a chance to shut down. Each of these likely needs individual review:
                 https://github.com/dotnet/reactive/issues/1927
 
+    IDE0028 - Suggests Collection expressions in place of construction, e.g. replaces new List<int>(x)
+              [.. x]. To me, this is less readable, and it doesn't improve performance, as far as we know.
+              Annoyingly, we don't seem to be able to configure this to apply only when it would not
+              introduce a spread.
     IDE0056 - Use of index/range syntax - relevant types not available on all targets, so we can't
     IDE0057     do this.
 
+    IDE0130 - Namespace does not match folder structure. Conforming to this would be a significant
+                upheaval, and it's not clear that it would be an improvement.
+
     IDE0290 - Primary ctors. This diagnostic suggests them in a lot of places where we don't want
                 them. E.g., in most types with multiple constructors I find I prefer not to have
                 a primary ctor. Since this is all or nothing, we turn it off.
@@ -84,11 +112,13 @@
                   [.. readyList]
               This won't improve performance as far as we know (sometimes a reason for using that
               syntax), and it's not obviously an improvement in readability.
+    IDE0306 - Suggests Collection expressions in place of construction, e.g. replaces new List<int>(x)
+              [.. x]. To me, this is less readable, and it doesn't improve performance, as far as we know.
 
     CA1510 - use ArgumentNullException.ThrowIf (not available on all targets)
     CA1513 - use ObjectDisposedException.ThrowIf (not available on all targets)
     -->
-    <NoWarn>$(NoWarn);CA1001;CA2213;CA1510;CA1513;IDE0056;IDE0057;IDE0290;IDE0305</NoWarn>
+    <NoWarn>$(NoWarn);CA1001;CA2213;CA1510;CA1513;IDE0028;IDE0056;IDE0057;IDE0130;IDE0290;IDE0305;IDE0306</NoWarn>
   </PropertyGroup>
 
   <ItemGroup>

Rx.NET/Source/Directory.build.targets

@@ -11,22 +11,39 @@
   </PropertyGroup>
   <PropertyGroup Condition="'$(TargetFramework)' == 'uap10.0.18362'">
     <DefineConstants>$(DefineConstants);HAS_WINRT;WINDOWS;HAS_OS_XAML;LEGACY_WINRT;NO_NULLABLE_ATTRIBUTES</DefineConstants>
-    <TargetPlatformVersion>10.0.19041.0</TargetPlatformVersion>
   </PropertyGroup>
   <PropertyGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
     <DefineConstants>$(DefineConstants);HAS_WINRT;NO_NULLABLE_ATTRIBUTES</DefineConstants>
   </PropertyGroup>
   <PropertyGroup Condition="$(TargetFramework.StartsWith('net6.0')) or $(TargetFramework.StartsWith('net7.0')) or $(TargetFramework.StartsWith('net8.0'))">
     <DefineConstants>$(DefineConstants);HAS_TRIMMABILITY_ATTRIBUTES</DefineConstants>
   </PropertyGroup>
-  <PropertyGroup Condition="$(TargetFramework.StartsWith('net6.0-windows')) or $(TargetFramework.StartsWith('net7.0-windows')) or $(TargetFramework.StartsWith('net8.0-windows'))">
+  <PropertyGroup Condition="$(TargetFramework.StartsWith('net6.0-windows')) or $(TargetFramework.StartsWith('net8.0-windows')) or $(TargetFramework.StartsWith('net9.0-windows'))">
     <DefineConstants>$(DefineConstants);HAS_WINRT;HAS_WINFORMS;HAS_WPF;HAS_DISPATCHER;DESKTOPCLR;WINDOWS;CSWINRT</DefineConstants>
   </PropertyGroup>
 
   <ItemGroup Condition="'$(TargetFramework)' == 'net472' or '$(TargetFramework)' == 'uap10.0.18362' or '$(TargetFramework)' == 'netstandard2.0'">
     <PackageReference Include="System.Threading.Tasks.Extensions" Version="4.5.4" />
   </ItemGroup>
 
+  <ItemGroup Condition="'$(TargetFramework)'=='uap10.0.18362'">
+    <PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform"
+                    Version="6.2.14" />
+  </ItemGroup>
+
+
+  <PropertyGroup Condition="$(TargetFramework.StartsWith('net6.0-windows')) or $(TargetFramework.StartsWith('net8.0-windows')) or $(TargetFramework.StartsWith('net9.0-windows'))">
+    <!--
+    In the 9.0.100-rc.2.24474.11 SDK, the build tools attempt to perform code generation for a whole load of our types to support WinRT interop.
+    It's looking like it does this for any public type that implements IDisposable!
+    It's possible that this is a bug in the SDK, but it's also possible that this will be resolved as by design.
+    For the .NET 9.0 RC2 SDK at least, we need to opt out the CsWinRT AOT optimizer.
+    We need to check whether this is definitely OK. I think this is only meant for types that are intended to be used from WinRT,
+    which isn't the case here, but we need to verify this.
+    -->
+    <CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>
+  </PropertyGroup>
+
   <Target Name="AddCommitHashToAssemblyAttributes" BeforeTargets="GetAssemblyAttributes">
     <ItemGroup>
       <AssemblyAttribute Include="System.Reflection.AssemblyMetadataAttribute" Condition=" '$(SourceRevisionId)' != '' ">