NETProvider
NETProvider copied to clipboard
FirebirdSQL
Dropping .NET 4.8 support
Is year 2024 year for dropping .NET 4.8 support?
There's multiple reasons why it would be nice. The codebase would be simpler and also allow use of "modern" .NET and C# features simplifying and cleaning the codebase even more. Together with that goes the (performance) features. And many more. I think we're all aware - on some level - of the benefits.
But I'd like to hear reasons why not to drop .NET 4.8? Why keep it?
At the moment I tend to think that netcoreapp3.1/netstandard2.1 could be the minimum supported versions.
Why not? Because the .net framework is the full, working, not dumbed down .net* staying with us while Windows exists. Who needs to touch everything in 2-3 years to be supported just to make the Cool Kids On The Code Block happy?
- Do anything serious and you need the abandoned parts: local reporting, workflow, communications foundations. There is no code access security, can't kick out something from an AppDomain, ... Everything dumbed down to Unix level. Don't let me start on the capabilities of the portable PowerShell on Windows ...
If .netstandard 2.0 (not only 2.1) will be support, net 4.8 could use the provider. Even when developers are on the way to core, it takes time and there are still a significant number of 4.8 apps out there. I support the plan to clean up. A version to be used with .net 4.8 is still neccessary from my point of view.
While I agree there's a need to have a version that supports .NET Standard 2.0 (and thus .NET Framewrok 4.x), I'm not sure that this backwards compatible version really needs to keep receiving new features. In other words I suggest to decide that major version X will drop .NET Standard 2.0 and .NET Framework, but keep version (X-1) published on NuGet and for some limited time do try to maintain it with serious bug fixes if any. People who need new features will have to migrate to .NET 5+ or something. If you need to stay at .NET Framework, then you need to stay at version X-1 and only receive bugfixes.
+1 to keep it as MS will support it 99% we are developing winforms.not a easy way to migrate winforms to .net core
+1 to keep too, we're developing a winforms application too and it's a huge amount of work to migrate
Hello Jiri...
Why not separate out the provider between one that will continue to support the standard .NET Frameworks up through 4.8.x and one that will support .NET Core 5.x through 8.x?
This way, the major upgrades can continue to the .NET Core version without concern for anything affecting the version for the standard .NET Frameworks. When you believe an update is required for this version then it can be accomplished without any concern for the one that supports the .NET Core versions.
It is true that you would have multiple code bases but then by separating out the providers, you will not have the problem of any conflicts between the support for both types of .NET Frameworks.
Considering that the .NET Core Frameworks would not be considered "mature" with all the constant upgrades, many of us are still working with the standard .NET Frameworks because they are more stable and for what many of us do, are perfectly workable for our endeavors.
If this wasn't the case then the question here wouldn't need to be asked...
Steve Naidamast Sr. Software Engineer
+1 for keep We developing Pos Apps with opos hardware like Epson, Diebold, IBM, Datalogic and much more and they still use .net 4.8 in Windows application. Indispensable for us.
Stefan
A question for all of you who vote to keep FW 4.8 support: Is it necessary to keep providing new features for you and your platform? Or would it suffice to just maintain the current latest version with bug fixes for a limited period of time and then just freeze it? I mean, the existing versions that support FW 4.8 won't disappear because new major versions drop that part, right?
And for you @cincuranet, would it be a good solution to drop FW 4.8 support moving forward (next major version), but maintain bugfix support for the current latest major version for a limited period of time?
For how long would the community need such bugfix support?
I would probably suggest to have a vote for which features to implement, if any, before freezing the feature set for the legacy FW 4.8 supporting major version. When those features are implemented, freeze that feature set and then, when starting work on next major version drop FW 4.8 support at that point.
Make sense?
It would be great to keep 4.8 or .net Standard 2.0 with the current and ongoing bugfixes, features etc.
BUT: We are asking here Jiri do deliver software service - just for free. Yes, I know that Firebird is an open source project. Having said that: I assume that Jiri (or other Firebird and Firebird .net Provider) developers have to pay their bills.
If the support for 4.8 or .net standard 2.0 would be droppend it might be no problem on the short run: We stick to the latest version 10 of the .net provider. In the case an issue pops up it would not be fixed as part of the ongoing product maintaince delivered by Jiri.
Long story short: What can we as .net provider 4.8 (or .net Standard 2.0) consumers do to keep it maintained? Is there a funding we should set up?
A question for all of you who vote to keep FW 4.8 support: Is it necessary to keep providing new features for you and your platform? Or would it suffice to just maintain the current latest version with bug fixes for a limited period of time and then just freeze it? I mean, the existing versions that support FW 4.8 won't disappear because new major versions drop that part, right?
I think it would be wonderful to connect to the latest Firebird database from .net framework 4.8.
I can get behind some funding for Jiri to assist him in maintaining two versions of the provider...
Steve Naidamast Sr. Software Engineer
Looks like we can sponsor @cincuranet via the heart icon on the top of the project screen. @cincuranet , can you get the amount sent via github? Looks like some tax data has to be filled.
I've read all the answers. Let me provide a summary response and we can then discuss more (and I'll now answer each comment with my view).
- Removing
net48support does not mean it's going away. You can still use whatever version is the last. You'll just not receive new features, etc., which I guess is fine given .NET Framework 4.8 is not receiving new features either. - I would consider releasing new version if (and only if) there's a critical bug found. Not a regular bug fixes. Only critical bugs (i.e. data corruption).
netstandard2.0is not the answer. It's basically same as API surface layer asnet48from provider POV.- Sponsoring me is fine, welcome and I would be grateful for that. But other side of the coin is my free time. And unless I can do it part-/full-time, my free time will be limited.
support for new FB versions like 5,6,etc will be possible in .net 4.8?
In terms of connecting yes. New features obviously not.
I'd wish that you'd keep it, but I can understand that you want to reduce the complexity of supporting old target frameworks.
I'm currently stuck supporting an MFC application, which has been around since the pre-2000 era and received tons of new features through the switch to C++/CLI and .NET Framework. Several discussions were needed to be allowed to upgrade the application to .NET Framework 4.7.2 this year. My customer freaked out when I told him that I'd like to drop support for Windows 7 customers. So, yeah, I'm still stuck in the .NET Framework world.
my opinion is to keep it,in .NET world Firebird is mostly used in winforms and NET 4.8 is mature,default installed in latest windows verions.NET CORE winforms seems not so important for Microsoft, it was added in NET 3.1 and I think not fully supported as older net framework
Ionut27:
I agree with your position and have voiced the same earlier.
What I am finding interesting is that increasingly I see more and more technicians voicing the fact that they are still heavily involved with development on the original .NET Frameworks. And why not? They still offer a better compliment of mature tools than the new .NET Core Frameworks, even if the latter may be more efficient.
Nonetheless, it seems that the .NET Core Frameworks are known more for what they don't have than what they do have...
Steve Naidamast Sr. Software Engineer
I'm using google translator
Currently, we are sparing no efforts to complete the company's entire architecture for net core, for two reasons, net framework discontinued by microsoft and the other performance. In Net Core, everything is faster from the start, not to mention that it can be run in a Linux environment, for example. So, in my opinion, there could be a cut in the provider for net framework support. This is bad, sure, but at some point it will have to be done.
Currently, we are sparing no efforts to complete the company's entire architecture for net core, for two reasons, net framework discontinued by microsoft ...
Not true, " _ ... will continue to be distributed with future releases of Windows. As long as it is installed on a supported version of Windows, .NET Framework 4.8.1 will continue to also be supported_", see the Framework lifecycle @ Microsoft. Check the lifecycle of your core @ Microsoft, happy main version migration in every 2-3 years.
And a sad note, if I will ever migrate something, then it will be the database server. Either to MS SQL Server (first class tooling) or to Postgresql (first class database).
I don't see why this has to be a choice of one over the other, and besides you would be excluding every extension in VS that utilizes your provider. That makes no sense. Plenty of the latest greatest software is coming out of .NET Framework and there are applications written using that architecture that I wouldn't dream of attempting in .NET, because let's be honest, despite all the moaning and groaning the Windows OS is light years ahead of any of it's counterparts. I don't believe there is a platform where I haven't been involved in software development, from the days of push/pop till now, and it doesn't take a genius to recognize, whether we like it or not, that the quality of software coming from Microsoft has no peer. Everyone knows this but seem to have a hard time acknowledging it. The guys developing software in their basements need to switch the light on.
Why not? Because the .net framework is the full, working, not dumbed down .net* staying with us while Windows exists. Who needs to touch everything in 2-3 years to be supported just to make the Cool Kids On The Code Block happy?
Yeah, the reason there is a .NET branch of .NET Framework is because we have other OS platforms out there that simply cannot live in the same space as the Windows OS. If you have a deep understanding of software you would know this.
I would like to see an application like VS written in .NET. Good luck with that.
I would like to see an application like VS written in .NET. Good luck with that.
Meet one: https://devblogs.microsoft.com/visualstudio/wpf-in-visual-studio-2010-part-1-introduction/
Meet one: https://devblogs.microsoft.com/visualstudio/wpf-in-visual-studio-2010-part-1-introduction/
WPF is born and bred in .NET Framework. I use use wpf in plenty of my .NET Framework applications. In fact BlackbirdSQL has wpf components.
VS is not a .NET application.
We are way off into offtopic land, but: https://devblogs.microsoft.com/visualstudio/visual-studio-2022-for-mac-preview-5/
We are way off into offtopic land, but: https://devblogs.microsoft.com/visualstudio/visual-studio-2022-for-mac-preview-5/
Underpins my point... that project died.
There are very few parts of the VS code I'm not familiar with, particularly the text editing, and it's all windows based with a few sprinklings of wpf.
The BlackbirdSQL SqlEditor integrates heavily into that code, which is 99.99% windows based, so Paul Harrington claiming that VS 2010 text editing was going to be predominantly wpf ended up as an absolute bs story.
All these pipe dreams of moving to .NET are not happening for the simple reason that .NET represents a small subset of the .NET Framework.
- Removing
net48support does not mean it's going away.
@cincuranet Ultimately it comes down to the spread of the Firebird client user base.
You would have a better idea of what that is than me, but it would surprise me if 90%+ were not on .NET Framework architecture.
.NET, in it's current form, is going to be long gone before .NET Framework is. It's more likely the two will eventually merge. .NET is not some magical architecture making Framework antiquated. The concept is great but it's implementation is plagued with problems. The demise of VS for Mac is a case in point. That project ended up being a bastardized imitation of a .NET Framework app.
So yeah, my guess is that without the .NET Framework user base, Firebird will become a relic from the past, and placing .Net Framework on the retired bench gives those users just another reason to move off of Firebird.