Update to .NET 7 and also nuget dependencies to current #192
Conversation
Windows 7 and 8.1 are not supported at all. They both reached end of extended support January 10, 2023, and should not be used or encouraged to be used. Whether .NET 6 technically will continue to run on these platforms I don't know, but also there, the official standpoint is that the lifecycle of .NET is the same as the underlying operating system, i.e. .NET 6 is not supported on Windows 7 and 8.1 . See dotnet/core#7556 . If @audiamus will consider an upgrade to .NET 6 instead it should not be difficult to "downgrade" this pull request. The big hurdle is from .NET Framework to .NET 5+. And upgrading to .NET 6 is better than staying with .NET Framework 4.8 in any case, for example the dependency to z440.atl.com requires an upgrade to .NET for version 5+, see https://www.nuget.org/packages/z440.atl.core#supportedframeworks-body-tab . |
|
Hello Svante, I will defer to audiamus for his position regarding .NET 6 and .NET 7 support on Windows 7; however, it is my understanding that AaxAudioConverter has already been updated to .NET6 support.
|
Not in the one and only master branch published on github - but there are some indications that maybe the gihub repo is not the primary location of the source code, but rather a publishing channel, so it could have been done elsewhere already. |
|
Ref: discussion [#170] It appears that only BookLibConnect is based on .NET 6 with AaxAudioConverter 2 being slated for .NET 6 or .NET 7. |
|
There are a number of reasons why I have not yet migrated AAXAudioConverter to .Net Core (5,6,7...). The plan is to merge BookLibConnect into AaxAudioConverter and hereby doing some redesign, e.g.:
BookLibConnect was written for .Net 5 and later updated to .Net 6. For this, a number of libraries in AaxAudioConverter have already been ported, identifiable by core as namespace prefix or assembly suffix. (I have been working with .Net Core since version 2 in my pro job and always kept the Core name to distinguish the code from classic .Net Framework.) There are also a few pitfalls when migrating from Framework to Core, not obvious at first glance, and not triggering compiler errors or warnings. I will probably skip .Net 7 altogether, because of its relatively short lifecycle. We have to see about Win 7. It may indeed happen that Win 7 can no longer be supported once my tools run with .Net 8. Only "big problem" is that I don't seem to find the time to tackle this in earnest, but it will happen. Therefore please understand that I won't want an intermediate "update" to .Net 7. |
Sounds nice!
Understood, for what it's worth, the PR does seem to work - but I have not tested extensively.
Yes, doing .NET 7 now is just a precursor to the LTS release of .NET 8. But it makes no sense really to go for .NET 6 either, the lifetime is almost the same as .NET 7.
Ok, understood. Hopefully you might find some useful stuff there anyway, some fixes to warnings such as comparing a struct with null and a fix to obsoleted dangerous use of rewriting strings with I did not spend much time on this anyway, and the only reason was I wanted to ensure use of the latest ATL library in relation to issue #193 , as I wanted to rule out that the issue was there and wanted to be able to build and use the latest & greatest there. Then, when I had done it, I thought I might as well at least offer it to you! So I won't be very disappointed if you throw it out ;-) . If you'd like some help, do contact me directly and perhaps I could be of some assistance and I may have some spare time. As a side note, it seems you're not really using github as your main development repository, but if you're interested in getting help with contributions, it facilitates if the development process is more transparent directly on github. I find this way of working is very good for my personal projects. |
That's correct. I prefer to develop independently of any web server. And my repo is SVN, not Git. I only export to Git once for each release. |
😉 Figured as much. There's some traces of Subversion in one of the project files... Your choice! But... I was once a Subversion fan, then TFS, then Mercurial - but although Mercurial really is better in many ways than Git, in the end it's not always what's best that wins the battle. Remember VHS vs. Betamax! So I gave up fighting city hall, and now only use Git. It works, quite well actually, and much better than Subversion and TFS anyway. Oh well, everybody to their own! |
Hi!
Here's a minimal but as far as I can tell, well working, upgrade of all projects to .NET 7, and all nuget packages to the latest current.
Much more can be done, but all warnings, including those related to the updates have been fixed, including some obsolete warnings.
I have not tried to build the Innosetup, but it should not really change anything. It is possible to build with .NET 7 a single executable, including embedded the whole .NET 7 code, trimming away all that's not needed etc in order to not require the consumer to have .NET 7 installed for example.
I don't really think it should be a problem to ask users to go to https://dotnet.microsoft.com/en-us/download/dotnet and download .NET 7, they'll be needing it anyway in many cases.
After releasing this, it should be fairly trivial to upgrade to .NET 8 when it's released as well.