Switch minimal requirements to .NET 5?

[Zeugma440]

Hi audiamus 👋 It's my turn to post on your Github ;)

I'm considering switching my library to .NET 5 in the future to be able leverage C#8.0 features such as reading binary data from a Stream directly into a Span for a lighter memory footprint and better performance. I have no deadline so far.

As of now, your app is the most starred project that is using ATL (according to Github at least), and is using .NET Framework v4.8.

Would it be difficult for you to switch the minimal requirements to .NET 5? Or do you consider your userbase not to be ready for this?

[audiamus]

My long term plan is to integrate Book Lib Connect with AAX Audio Converter. Book Lib Connect is based on .Net 6. The new AAX Audio Converter 2.* then will also be based on .Net 6 (or 7). That integration will be quite a bit of work and I have postponed it, not being able to allocate the necessary time in recent months. For now, I will still add minor new features to AAX Audio Converter 1.*, but it will remain .Net Framework 4.8, as there are quite a few .Net Framework-specific dependencies. Only one or two of those I have ported to .Net Standard/Core for Book Lib Connect until now. But I plan to address this task for real in the upcoming months, after a holiday in April.

With new AAX Audio Converter 2.* I also will abandon FFmpeg sub-processes and use many more features of Mbucari/AAXClean which already handles the decryption in Book Lib Connect. On my request Mbucari has implemented almost all of the other FFmpeg features I need, e.g. silence detection. And there are more challenges with in-process handling of audio manipulation as I need a new approach to my little gimmick of visual performance monitoring.

So, in the long term, I don't see a problem for AAX Audio Converter if you switch to the .Net Core family (I wouldn't go for .Net 5, though, as it is already out of support). But you could keep a release branch in GIT for .Net Standard, to be able to apply patches, if necessary. That's what I already do with my AAX Audio Converter code. (I am a Subversion guy and keep my subversion repo locally, only release code gets uploaded to the Github repo.)

There is a challenge for users, though, and you indicate it: Classic .Net Framework is regarded by Microsoft as a component of the Windows operating system and is updated with the Windows update mechanism automatically, without further ado. The .Net Core family of runtimes, however, is not a Windows component and only updated by Windows Update, if you explicitly add it.

BTW, with FFmpeg, I always drop the meta data when copying/converting the audio files and rebuild it from scratch with your ATL.net. Does your lib have a feature to explicitly clear all meta data before rebuilding it? Mbucari's tools leave meta data untouched.

[Sailfish]

As always, the responses are quick and through, much appreciated.

Is it correct for me to assume that once new AAX Audio Converter 2 is released and deemed stable that AAX Audio Converter 1 will be legacied as some point afterward? Also, are there any implications that Windows 7 users need to be prepared for?

[audiamus]

Also, are there any implications that Windows 7 users need to be prepared for?

One of my ideas is to activate the dynamic colouring of the task bar icon for additional progress report or error state. But I think this feature was introduced with Win7, although it could be disabled and wasn't used by that many applications.

While I still have two Win7 machines at home, I do not use them for development. The 32bit Win7 of those seems too old to be able to even contact GitHub for AAX Audio Converter updates. I guess an SSL/TLS problem as I mentioned in the other thread. The 64bit machine I kept up to date. However, when (not if) that one fails, I will no longer run Win7 tests.

The .Net 6 runtime does run on Win 7, otherwise Book Lib Connect wouldn't work for you. Not sure about .Net 7, haven't used it yet and haven't looked into the specs.

[Sailfish]

Thanks. btw, when your 64bit Win7 fails and you're still interested in supporting Win7, I would be pleased to run your system tests on my system, if you wished.

Just to confirm, yes, I did insure that I had both .Net 5.0.214(64) AND .Net 6.0.310(64) installed

Thanks, again.

[Zeugma440]

Thanks a bunch for the detailed answer!

You're completely right about using .NET 6 rather than 5. I was reasoning "base requirement" with 5, but realistically, 6 would be the way to go.

I plan to address this task for real in the upcoming months, after a holiday in April.

Nice ! I'll have a look a couple months later then.

But you could keep a release branch in GIT for .Net Standard, to be able to apply patches, if necessary

That's what I would do if I decided to migrate sooner, but I'd rather not to, as backporting important fixes on a legacy branch would require more and more effort as the most recent branch gets modernized and refactored. A 12-month support is the best I can do in that scenario.

Does your lib have a feature to explicitly clear all meta data before rebuilding it? Mbucari's tools leave meta data untouched.

You can use Track.Remove for that 😉

[audiamus]

You can use Track.Remove for that

Excellent!

Regarding C# and .Net versions, you are probably aware of all the following:

• The highest version of .Net Standard that can be used with both .Net Framework and .Net Core is 2.0. Hence, 2.1 doesn't really make much sense.
• C# compiler version and .Net version are related but somewhat independent of each other. You can use newer compiler features with older .Net runtimes as long as the compiler feature does not rely on specific classes in the .Net library. For this you have to set the compiler version <LangVersion> in the project file.
• Some .Net classes required by a newer compiler are separately available as NuGet packages.
• You can even use C#9 record with .Net Standard 2.0:

// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
// See the LICENSE file in the project root for more information.

// NOTE: This source file can be added as link in any .Net Standard or .Net Core (<= 3.1) class library to allow new .Net 5 "record" type.
// NOTE: Such class library must support C#9: <LangVersion>9.0</LangVersion> (in <PropertyGroup>)

#if NETSTANDARD2_0 || NETSTANDARD2_1 || NETCOREAPP2_0 || NETCOREAPP2_1 || NETCOREAPP2_2 || NETCOREAPP3_0 || NETCOREAPP3_1 || NET45 || NET451 || NET452 || NET6 || NET461 || NET462 || NET47 || NET471 || NET472 || NET48

using System.ComponentModel;

// ReSharper disable once CheckNamespace
namespace System.Runtime.CompilerServices {
  /// <summary>
  /// Reserved to be used by the compiler for tracking metadata.
  /// This class should not be used by developers in source code.
  /// </summary>
  [EditorBrowsable (EditorBrowsableState.Never)]
  internal static class IsExternalInit {
  }
}

#endif

[Zeugma440]

FYI, I'm currently polishing the next major version of ATL, which drops support for .NET Framework 4.8 in favour of .NET 6.0, solves the "duplicate code for sync and async methods" dilemma and modernizes the structure of testing projects.

The release should happen during August.

[audiamus]

That isn't a problem. Just go ahead. I haven't come very far yet with my integration of the tools - so many other things to do. But I'm fine with the current version of ATL. And if some major issue comes up it will have to wait until AAX Audio Converter is also .Net (core) 6.