adds support for .NET 8.0

[prathikr]

#628

[jsquire]

If your intent is to use the constants that are being defined in the code to determine what platform you're running on, this approach isn't going to work. This will tell you the build-time platform only. You may want to consider removing these and using a runtime check.

For example, this will cover all supported platforms:

 using System.Runtime.InteropServices;
 
 public static class PlatformHelper
 {
     public static bool IsWindows =>
 #if NET5_0_OR_GREATER
         OperatingSystem.IsWindows();
 #else
         RuntimeInformation.IsOSPlatform(OSPlatform.Windows);
 #endif
 
     public static bool IsLinux =>
 #if NET5_0_OR_GREATER
         OperatingSystem.IsLinux();
 #else
         RuntimeInformation.IsOSPlatform(OSPlatform.Linux);
 #endif
 
     public static bool IsMacOS =>
 #if NET5_0_OR_GREATER
         OperatingSystem.IsMacOS();
 #else
         RuntimeInformation.IsOSPlatform(OSPlatform.OSX);
 #endif
 
     public static string OSDescription =>
         RuntimeInformation.OSDescription;
 
     // Version-gated check (only precise on .NET 5+)
     public static bool IsWindowsVersionAtLeast(int major, int minor = 0, int build = 0) =>
 #if NET5_0_OR_GREATER
         OperatingSystem.IsWindowsVersionAtLeast(major, minor, build);
 #else
         RuntimeInformation.IsOSPlatform(OSPlatform.Windows)
             && Environment.OSVersion.Version >= new Version(major, minor, build);
 #endif
 }

The .NET Framework targets would need the System.Runtime.InteropServices.RuntimeInformation polyfill package from NuGet.

[jsquire]

I'd assume you would want to run your tests on net462 as well, since it's the lowest supported .NET Framework version.

[prathikr]

We do not want to support lower than net8.0

[scottaddie]

We do not want to support lower than net8.0

@prathikr Does that imply you don't want .NET Framework customers using the library? For clarity, TFM net462 corresponds to .NET Framework 4.6.2.

[jsquire]

We do not want to support lower than net8.0

It's a valid decision, but it runs counter to the common developer experience and guidelines for both Azure Foundry and Azure itself. Was this limitation discussed with leadership or made in isolation?

[jsquire]

In this context, since you've added netstandard2.0 to your project targets, not running a .NET Framework leg in your tests does not remove support for it from the product - it simply leaves all .NET Framework runtimes untested. Since there is a divergence between runtimes, this exposes you to a nasty class of bugs that is hard to root cause in isolation.

I'd very, very strongly suggest that you align your test runs with the frameworks that your product supports.

[jsquire]

nit: There's no benefit to using 9.x here. I'd suggest aligning them to your 8.x dependency.

[prathikr]

Is there a downside to using 9.x?

[jsquire]

For this specific set, not that I see. Generally, yes. Many of the BCL packages are polyfills on modern runtimes and those on your version line would be able to elide the package entirely and use the built-in version.

[jsquire]

Foundry is aligned on the official OpenAI library for its developer experience. Why is a random third-party package used here?

[scottaddie]

I created #632 to track that problem.

[prathikr]

yes, we are in the process of moving off this dependency

[scottaddie]

Is there a target date for completion of that work? Let us know if you have questions. Jesse and I represent the team that ships the official OpenAI library.

[prathikr]

It is still under discussion, will update when I have a timeline.

[jsquire]

Expanding on my comment in the tests project - there's a misalignment here between what runtimes your product supports (this list) and what you're actively testing.

Your statement about not wanting to support runtimes earlier than 8.0 is in opposition to the target list here, as netstandard2.0 will allow running on the supported .NET Framework runtimes (4.26 - 4.81).

Note that doing so is compliant with the Azure developer experience guidelines and the Azure Foundry developer experience across products.

[prathikr]

ok, will add netstandard2.0 for cross-platform and net462 for winml. is that the correct setup to be compliant with Azure Foundry developer experience?

[jsquire]

Is there a reason why you need to explicitly state the RuntimeIdentifiers in the general case? Do you have a native dependency bound to these?

[prathikr]

Yes, we have a Foundry Local Core dependency which is a native AOT c# application.