Config and filename adjustments, to allow for building on Linux.

Author: JakenVeina

AsyncRx.NET/Directory.build.props renamed to AsyncRx.NET/Directory.Build.props

@@ -27,7 +27,7 @@ At the time of writing this, the current version of `System.Interactive` is 6.0.
     * `net6.0`
     * `netstandard2.1`
 
-  
+
 The use of `net4.8` in `ref` seems to have been a bug: that should have been `net48`. (The main reason I am confident it's a bug, and not a clever but obscure trick that we've not understood, is that the [commit of 2021/12/06 that added this](https://github.com/dotnet/reactive/commit/a2410b2267abe193191f3894d243771ae4b126fd) used [`net48` in reference assemblies for one of the other packages](https://github.com/dotnet/reactive/commit/a2410b2267abe193191f3894d243771ae4b126fd#diff-3b568c93a468dab1b1a619a450bf1c4d88d3ec9539737d09fa6fb7659bc0ae5fR7), so this just seems to have been a slip.)
 
 The other discrepancy is that we have `netstandard2.0` in the `lib` folder but `netstandard2.1` in the ref folder. At first glance, this too looks quite a lot like a mistake, particularly when you examine the history. Here is the point in the release history at which the `ref` folder first started having a `netstandard2.1` folder:
@@ -45,12 +45,12 @@ And yet, on closer inspection, this appears to be deliberate. Looking at this co
 
   https://github.com/dotnet/reactive/commit/0252fb537c9d335b9bc863b65291f152c07ba385
 
-  we see a [comment in Ix.NET/Source/refs/Directory.build.props](https://github.com/dotnet/reactive/commit/0252fb537c9d335b9bc863b65291f152c07ba385#diff-909504334cbab5c432709c95ae78c24fb2910d850958af2ef6de444b18e5c8ecR6) saying:
-  
+  we see a [comment in Ix.NET/Source/refs/Directory.Build.props](https://github.com/dotnet/reactive/commit/0252fb537c9d335b9bc863b65291f152c07ba385#diff-909504334cbab5c432709c95ae78c24fb2910d850958af2ef6de444b18e5c8ecR6) saying:
+
 > This is here so we can create a fake .NET Standard 2.1 facade
 
 I can only guess that they knew .NET Standard 2.1 was coming, and wanted to ensure that `System.Interactive` was ready for it when it shipped.
-  
+
 So it was deliberate. But offering reference assemblies for a platform without any corresponding implementation for that platform is an odd choice. (And although at the time this was a placholder for a forthcoming .NET Standard version, it continued to look like this after .NET Standard 2.1 shipped. All subsequent Ix.NET releases have continued to provide `netstandard2.1` in the `ref` folder with no matching folder in `lib`. So it wasn't just a temporary measure.) What purpose does this serve?
 
 Some of the features that Ix offers eventually became available in .NET Core, such as `EnumerableEx.SkipLast`. This method exists in the implementation assemblies for every TFM of Ix.NET, but the `netstandard2.1` and `net6.0` reference assemblies omit it. This has the effect that if you're targetting any version of .NET recent enough to have these methods built into the .NET runtime libraries, the Ix.NET equivalents will:

Ix.NET/Documentation/adr/0001-Ix-Ref-Assembly-Mismatches.md

@@ -11,8 +11,8 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution
 		AsyncQueryableGenerator.t4 = AsyncQueryableGenerator.t4
 		..\..\azure-pipelines.ix.yml = ..\..\azure-pipelines.ix.yml
 		CodeCoverage.runsettings = CodeCoverage.runsettings
-		Directory.build.props = Directory.build.props
-		Directory.build.targets = Directory.build.targets
+		Directory.Build.props = Directory.Build.props
+		Directory.Build.targets = Directory.Build.targets
 		global.json = global.json
 		NuGet.Config = NuGet.Config
 		version.json = version.json

Ix.NET/Source/Ix.Async.NET.sln

@@ -13,8 +13,8 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution
 		..\..\.editorconfig = ..\..\.editorconfig
 		..\..\azure-pipelines.ix.yml = ..\..\azure-pipelines.ix.yml
 		CodeCoverage.runsettings = CodeCoverage.runsettings
-		Directory.build.props = Directory.build.props
-		Directory.build.targets = Directory.build.targets
+		Directory.Build.props = Directory.Build.props
+		Directory.Build.targets = Directory.Build.targets
 		version.json = version.json
 	EndProjectSection
 EndProject
@@ -61,7 +61,7 @@ Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "FasterLinq", "FasterLinq\Fa
 EndProject
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Refs", "Refs", "{A3D72E6E-4ADA-42E0-8B2A-055B1F244281}"
 	ProjectSection(SolutionItems) = preProject
-		refs\Directory.build.props = refs\Directory.build.props
+		refs\Directory.Build.props = refs\Directory.Build.props
 	EndProjectSection
 EndProject
 Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "System.Interactive", "refs\System.Interactive\System.Interactive.csproj", "{2EC0C302-B029-4DDB-AC91-000BF11006AD}"

Ix.NET/Source/Ix.NET.sln

@@ -74,9 +74,9 @@ The following sections describe how we will deal with each of the issues raised
 
 In all projects that used to target `net5.0`, change this to `net6.0`. Likewise, in any projects that target `net5.0-windows10.0.19041`, change that to `net6.0-windows10.0.19041`.
 
-Modify the entries in `Directory.build.targets`
+Modify the entries in `Directory.Build.targets`
 
-Remove the entries in `Directory.build.targets` that refer to the out-of-support TFMs. This means that several preprocessor constants are no longer used. We should scour the codebase and remove all conditionally compiled sections of code that will no longer be used because the target frameworks that used to bring them in no longer exist. The constants no longer in use are:
+Remove the entries in `Directory.Build.targets` that refer to the out-of-support TFMs. This means that several preprocessor constants are no longer used. We should scour the codebase and remove all conditionally compiled sections of code that will no longer be used because the target frameworks that used to bring them in no longer exist. The constants no longer in use are:
 
 * `NETSTANDARD1_0`
 * `NETSTANDARD1_3`

Rx.NET/Documentation/adr/0001-net7.0-era-tooling-update.md

@@ -99,14 +99,14 @@ Note that the specific version we actually want to target, 18362, isn't in there
 
 The following sections explain how we enable `uap10.0.18362` to be specified as a target framework, even though the tools do not support this.
 
-The project has `Directory.build.props` and `Directory.build.targets` files. The build tools search for these and automatically load them for all projects in the solution. The `Directory.build.props` file has a `<PropertyGroup>` with a `Condition` that means it runs only when the `uap10.0.18362` target is being built, and it sets numerous properties, as described in the following sections.
+The project has `Directory.Build.props` and `Directory.Build.targets` files. The build tools search for these and automatically load them for all projects in the solution. The `Directory.Build.props` file has a `<PropertyGroup>` with a `Condition` that means it runs only when the `uap10.0.18362` target is being built, and it sets numerous properties, as described in the following sections.
 
 
 #### Target Platform Version
 
 We make our minmum platform version match the one in the TFM:
 
-```xml   
+```xml
 <TargetPlatformMinVersion>10.0.18362</TargetPlatformMinVersion>
 <TargetPlatformVersion>10.0.18362.0</TargetPlatformVersion>
 ```
@@ -130,7 +130,7 @@ However, only _some_ properties should use the old name. We need to set _all_ of
 
 #### Compiler Constants
 
-When using the supported UWP build tools (with the old-form project system, which we can't use because we also need to build modern targets), the `WINDOWS_UWP` define constant is set, enabling source code compiled into multiple targets to detect that it is being built for UWP with a `#if WINDOWS_UWP`. So we need this in `Directory.build.props`:
+When using the supported UWP build tools (with the old-form project system, which we can't use because we also need to build modern targets), the `WINDOWS_UWP` define constant is set, enabling source code compiled into multiple targets to detect that it is being built for UWP with a `#if WINDOWS_UWP`. So we need this in `Directory.Build.props`:
 
 ```xml
 <DefineConstants>$(DefineConstants);WINDOWS_UWP</DefineConstants>
@@ -141,15 +141,15 @@ When using the supported UWP build tools (with the old-form project system, whic
 
 Normally, when you specify a TFM, the .NET SDK works out what framework library references are required and adds them for you. So if you write `<TargetFramework>net8.0<TargetFramework>` in a project file, you will automatically have access to all the .NET 8.0 runtime libraries. But because the .NET SDK does not support UWP, this doesn't work at all. So we need to do three things.
 
-First, we need to set this property in `Directory.build.props`:
+First, we need to set this property in `Directory.Build.props`:
 
 ```xml
 <NoStdLib>True</NoStdLib>
 ```
 
 Without this, the build tools attempt to add a reference to `mscorlib.dll`, but they don't seem to realise that a) this is the wrong thing and b) they don't actually have a correct location for that, so the reference ends up being `\mscorlib.dll` (i.e., it looks on the root of the hard drive).
 
-Second we need an `ItemGroup` in `Directory.build.targets` containing this:
+Second we need an `ItemGroup` in `Directory.bBild.targets` containing this:
 
 ```xml
 <PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform"
@@ -171,7 +171,7 @@ You might be wondering about that 26100 in there. Why is that not 18362, consist
 
 #### Prevent Over-Zealous WinRT Interop Code Generation
 
-The .NET SDK has a feature by which it can generate WinRT versions of .NET types to enable interop between .NET and WinRT code. Unfortunately, the way we've rigged things up to be able to build for `uap10.0.18362.0` seems to cause this to generate these interop types for any .NET class that implements `IDisposable`! This is not helpful. So we disable the feature in `Directory.build.targets`:
+The .NET SDK has a feature by which it can generate WinRT versions of .NET types to enable interop between .NET and WinRT code. Unfortunately, the way we've rigged things up to be able to build for `uap10.0.18362.0` seems to cause this to generate these interop types for any .NET class that implements `IDisposable`! This is not helpful. So we disable the feature in `Directory.Build.targets`:
 
 ```xml
 <CsWinRTAotOptimizerEnabled>false</CsWinRTAotOptimizerEnabled>

Rx.NET/Documentation/adr/0003-uap-targets.md

@@ -18,11 +18,12 @@
     <EmbedUntrackedSources>true</EmbedUntrackedSources>
     <PublishRepositoryUrl>true</PublishRepositoryUrl>
     <LangVersion>latest</LangVersion>
+    <EnableWindowsTargeting>true</EnableWindowsTargeting>
   </PropertyGroup>
 
   <PropertyGroup Condition="'$(Configuration)' != 'Debug'">
     <IncludeSymbols>true</IncludeSymbols>
-    <SymbolPackageFormat>snupkg</SymbolPackageFormat>    
+    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
   </PropertyGroup>
 
   <PropertyGroup Condition="'$(TF_BUILD)' == 'true'">
@@ -31,7 +32,7 @@
 
   <ItemGroup>
     <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.1.1" PrivateAssets="All"/>
-    
+
     <!--
     Nerdbank.GitVersioning 3.6.128 injects a reference to a .proj file that doesn't work inside the
     UWP test runner project. We don't ship that as a NuGet package, so it doesn't matter what its

Rx.NET/Source/Directory.build.props renamed to Rx.NET/Source/Directory.Build.props

@@ -1,11 +1,11 @@
 <Project>
 
   <!-- This props all need to be set in targets as they depend on the values set earlier -->
-  
-  <PropertyGroup>  
+
+  <PropertyGroup>
     <Product>$(AssemblyName) ($(TargetFramework))</Product>
   </PropertyGroup>
-    
+
   <PropertyGroup Condition="'$(TargetFramework)' == 'net472'">
     <DefineConstants>$(DefineConstants);HAS_WINFORMS;HAS_WPF;HAS_WINRT;HAS_DISPATCHER;HAS_REMOTING;DESKTOPCLR;NO_NULLABLE_ATTRIBUTES</DefineConstants>
   </PropertyGroup>

Rx.NET/Source/Directory.build.targets renamed to Rx.NET/Source/Directory.Build.targets

@@ -19,8 +19,8 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution
 		.editorconfig = .editorconfig
 		analyzers.globalconfig = analyzers.globalconfig
 		..\..\azure-pipelines.rx.yml = ..\..\azure-pipelines.rx.yml
-		Directory.build.props = Directory.build.props
-		Directory.build.targets = Directory.build.targets
+		Directory.Build.props = Directory.Build.props
+		Directory.Build.targets = Directory.Build.targets
 		global.json = global.json
 		Rx.ruleset = Rx.ruleset
 		Test.ruleset = Test.ruleset
@@ -30,13 +30,13 @@ EndProject
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Tests", "Tests", "{D324579D-CBE6-4867-8980-D7842C7C45A2}"
 	ProjectSection(SolutionItems) = preProject
 		tests\.editorconfig = tests\.editorconfig
-		tests\Directory.build.props = tests\Directory.build.props
-		tests\Directory.build.targets = tests\Directory.build.targets
+		tests\Directory.Build.props = tests\Directory.Build.props
+		tests\Directory.Build.targets = tests\Directory.Build.targets
 	EndProjectSection
 EndProject
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Facades", "Facades", "{A0F39260-B8F8-4FCB-9679-0ED917A22BDF}"
 	ProjectSection(SolutionItems) = preProject
-		facades\Directory.build.props = facades\Directory.build.props
+		facades\Directory.Build.props = facades\Directory.Build.props
 		facades\System.Reactive.Compatibility.nuspec = facades\System.Reactive.Compatibility.nuspec
 	EndProjectSection
 EndProject

Rx.NET/Source/System.Reactive.sln

@@ -1,5 +1,5 @@
 <Project>
-  <Import Project="..\Directory.build.props" />
+  <Import Project="..\Directory.Build.props" />
   <PropertyGroup>
     <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
     <GenerateAssemblyVersionInfo>false</GenerateAssemblyVersionInfo>