Implenets cleaner .NET SDK version light up

Directory.Build.props

@@ -83,6 +83,11 @@
                 <ImplicitUsings>disable</ImplicitUsings>
                 <!-- NOTE: Top-Level statements blocked as an error in .editorconfig and ImplicitUsings 'feature' VERIFIED in the targets file -->
             </PropertyGroup>
+
+            <!--
+            Apply SyleCop settings to all projects; It is at least plausible to do this in a .editorconfig but there's no docs on
+            how. Only a PR and multiple bugs/discussions pointing to it. It's too big to decipher to make it worth using. Docs please.
+            -->
             <ItemGroup Condition="'$(NoCommonAnalyzers)'!='true'">
                 <AdditionalFiles Include="$(MSBuildThisFileDirectory)stylecop.json" Link="stylecop.json" />
             </ItemGroup>

Directory.Build.targets

@@ -1,4 +1,10 @@
 <Project InitialTargets="VerifyProjectSettings;ShowBuildParameters;EnsureBuildOutputPaths">
+
+     <!--This must go in the targets as the directory imports occur BEFORE $(NETCoreSdkVersion) is set and would end up blank -->
+    <PropertyGroup Condition="'$(NETCoreSdkVersion)'!='' AND $([MSBuild]::VersionGreaterThanOrEquals('$(NETCoreSdkVersion)', '10.0.0'))">
+        <DefineConstants>$(DefineConstants);NET_SDK_10_OR_GREATER</DefineConstants>
+    </PropertyGroup>
+
     <!--
     Since Nuget.config is configured to include the build output location this
     will ensure the folder exists during restore so that it won't fail.
@@ -19,6 +25,7 @@
         <Message Importance="normal" Text="               FileVersion: $(FileVersion)"/>
         <Message Importance="normal" Text="                  Platform: $(Platform)"/>
         <Message Importance="normal" Text="             Configuration: $(Configuration)"/>
+        <Message Importance="normal" Text="         NETCoreSdkVersion: $(NETCoreSdkVersion)"/>
     </Target>
 
     <Target Name="VerifyProjectSettings" Condition="'$(MSBuildProjectExtension)'=='.csproj'">

src/Analyzers/RepositoryVerifier.UT/ExtensionsKeywordAnalyzerTests.cs

@@ -3,7 +3,8 @@
 
 // This isn't a normal built-in define; but follows the pattern for built-in defines and expresses the intent.
 // There is no Known way to "light up" at runtime for functionality available in newer versions
-#if COMPILER_5_OR_GREATER
+// See: Directory.Build.targets for how this is set. (Roslyn compiler v5.x is included in .NET 10)
+#if NET_SDK_10_OR_GREATER
 using System.Threading.Tasks;
 
 using Microsoft.CodeAnalysis;

src/Analyzers/RepositoryVerifier/ExtensionKeywordAnalyzer.cs

@@ -3,7 +3,8 @@
 
 // This isn't a normal built-in define; but follows the pattern for built-in defines and expresses the intent.
 // There is no Known way to "light up" at runtime for functionality available in newer versions
-#if COMPILER_5_OR_GREATER
+// See: Directory.Build.targets for how this is set. (Roslyn compiler v5.x is included in .NET 10)
+#if NET_SDK_10_OR_GREATER
 using System.Collections.Immutable;
 
 using Microsoft.CodeAnalysis;

src/Interop/Ubiquity.NET.Llvm.Interop/ReadMe.md

@@ -15,12 +15,13 @@ This library contains the low level interop between managed code and the native
 for more info]  
 
 Firstly it's young, poorly understood, barely even documented and not what is considered
-by many as stable/mature yet. But, mostly because it requires everything to compile AOT to work. That
-is, it's all or nothing and doesn't support use in an either or model (traditional JIT runtime,
-or AOT). Somethings are not yet supporting AOT/Trimming scenarios. (In the case of the samples
-in this repo the DGML graph builder used employs XML serialization, which in turn requires
-dynamic reflection to work. This required a custom solution to resolve. So, as great a feature
-AOT is it is not without issues at present. Perhaps over time it will become the normal state
-and more libraries will build in a way as to support it. (This library has a motivation to go
-there in that it's broader use is specifically for AOT code generation! Thus it's a bit on the
-"bleeding edge" of things.)
+by many as stable/mature yet. But, mostly because it requires everything to compile AOT to
+work. That is, it's all or nothing and doesn't support use in an either or model
+(traditional JIT runtime, or AOT). Somethings are not yet supporting AOT/Trimming scenarios.
+
+In the case of the samples in this repo the DGML graph builder used employs XML
+serialization, which in turn requires dynamic reflection to work. This required a custom
+solution to resolve. So, as great a feature AOT is it is not without issues at present.
+Perhaps over time it will become the normal state and more libraries will build in a way as
+to support it. (This library has a motivation to go there in that it's broader use is
+specifically for AOT code generation! Thus it's a bit on the "bleeding edge" of things.)