Feature request: target .NET Framework 3.5 (net3.5)

[StipoR]

.NET Framework 3.5 is officially supported by Microsoft till Jan 9, 2029 (see https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework) which is longer than any current and a couple of future versions of .NET (see https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core).

There are still a lot of NuGet packages that target .NET Framework 3.5 (net3.5) and would like to reference the official BouncyCastle.Cryptography NuGet package.

This would also help with increasing the popularity of the official BouncyCastle.Cryptography NuGet package among other unofficial BouncyCastle NuGet packages.

[webprofusion-chrisc]

That would be OK if the maintainers worked at Microsoft but I don't think they do and it's otherwise unfair to unnecessarily burden them with supporting a framework from 2007.

What's stopping you moving your own project to .net 4.8.1 (or other 4.x with open support end date)? Server 2022 ships with 4.8 so with extended support you're looking at 2032,

[StipoR]

That would be OK if the maintainers worked at Microsoft but I don't think they do and it's otherwise unfair to unnecessarily burden them with supporting a framework from 2007.

Well, I managed to port this code to .NET Framework 3.5 in about a half an hour because the code doesn't use almost any .NET or C# feature that wasn't available in .NET Framework 3.5. I had to do the following changes to successfully target .NET Framework 3.5:

• Removed PackageReference to Nerdbank.GitVersioning when targeting net35 because the auto-generated file BouncyCastle.Cryptography.Version.cs (in the obj folder) uses assembly attribute System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage which is not available in .NET Framework 3.5. This should probably be handled in a better way.
• Replaced ISet<T> with HashSet<T> when targeting net35 (by utilizing the NET35 preprocessor symbol). This was done with the Visual Studio's Find & Replace tool.
• Removed 'out' keyword from the Org.BouncyCastle.Utilities.Collections.IStore<out T> when targeting net35 because .NET Framework 3.5 doesn't support covariant type parameters.
• Changed handling of the Org.BouncyCastle.Tls.RecordStream.Close method because ExceptionDispatchInfo is not available in .NET Framework 3.5.
• Added public static Asn1EncodableVector FromEnumerable<T>(IEnumerable<T> e) where T : Asn1Encodable to the Org.BouncyCastle.Asn1.Asn1EncodableVector class and public static void AddRange<T, U>(this List<T> list, IEnumerable<U> items) where U : T to the Org.BouncyCastle.Utilities.Collections.CollectionUtilities class (also changed abstract class to static class so it can host extension methods) because .NET Framework 3.5 doesn't support implicit conversion of interfaces with covariant type parameters.
• In the Org.BouncyCastle.Bcpg.ArmoredOutputStream.CreateVersion method, using ((TAttribute)Attribute.GetCustomAttribute(assembly, typeof(TAttribute))).
• Added internal static TValue VolatileRead(ref TValue field) to the Org.BouncyCastle.Utilities.Objects class because the Volatile.Read is not available in .NET Framework 3.5.
• In the Org.BouncyCastle.Crypto.Prng.CryptoApiRandomGenerator.Dispose method, trying to cast m_randomNumberGenerator field to IDisposable and disposing it.

Based on this, the cost of adding and maintaining support for .NET Framework 3.5 justifies the gains. But even if support for .NET Framework 3.5 doesn't get added, I think the other issue that I have reported (https://github.com/bcgit/bc-csharp/issues/447) should be addressed because it is not related to the legacy framework.

What's stopping you moving your own project to .net 4.8.1 (or other 4.x with open support end date)? Server 2022 ships with 4.8 so with extended support you're looking at 2032,

I work for a company that develops and sells several library assemblies (.NET dlls) for working with Office and PDF files and some percenage of our customers rely on the fact that they can use our assemblies in their projects that are tied to .NET Framework 3.5 for various reasons. They can use various Office and PDF cryptography features because our assemblies use the unofficial BouncyCastle NuGet package when targeting .NET Framework 3.5. But we would like to continue providing these functionalities using the official BouncyCastle.Cryptography NuGet package.

[mellamokb]

Second this. We were porting an old legacy website from Server 2008 R2 to Server 2019, but because of some dependencies it is still required to run on .NET Framework 3.5. I want to generate some hashes for some legacy cryptography verification that are not supported anymore, and this library seems to be the answer, but I need to be able to run it in .NET Framework 3.5.