Dropping .NET 4.8 support #1155
Comments
|
At the moment I tend to think that |
|
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?
|
|
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. |
|
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 |
|
+1 to keep too, we're developing a winforms application too and it's a huge amount of work to migrate |
|
+1 for keep it,winforms too |
|
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 |
|
+1 for keep 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? |
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 |
|
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).
|
|
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 |
|
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. |
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). |
|
+1 for keep winforms |
|
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. |
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. |
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/ |
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. |
@cincuranet Ultimately it comes down to the spread of the .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. 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. |
|
Greg...
When you get a chance could you please clarify your arguments below?
To me, it appears you are saying that the original .NET Framework will outlast the new .NET Core Frameworks.
If this is the case, I could agree with you considering that so much has been removed from the original frameworks with the new versions.
Steve Naidamast
Sr. Software Engineer
…________________________________
From: Greg Alexander ***@***.***>
Sent: Friday, March 15, 2024 5:10 AM
To: FirebirdSQL/NETProvider ***@***.***>
Cc: snaidamast ***@***.***>; Comment ***@***.***>
Subject: Re: [FirebirdSQL/NETProvider] Dropping .NET 4.8 support (Issue #1155)
* Removing net48 support does not mean it's going away.
@cincuranet<https://github.com/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.
—
Reply to this email directly, view it on GitHub<#1155 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE3NTJV4GPMSKYL4O3QC3L3YYK3HJAVCNFSM6AAAAABB3KJ62CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJZGIZDOMBZGU>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Hi Steve. Yes, that is what I am saying. So in .NET heaven we develop a piece of serious desktop software, for example Visual Studio, Adobe AE, Autodesk Inventor or Maya, and it magically runs seamlessly on Windows, Mac, Linux, Android and iOS. So where is all this successful cross-platform software? Well it's either directly ported, or on a virtual machine or translator. Given all this I just don't see how .NET could possibly outlast .NET Framework, because Microsoft's OS superiority is here to stay. |
|
BlackbirdSQL\Greg... I believe that Microsoft made a big mistake with its move to the .NET Core Frameworks in the way they handled the migration. As I had mentioned previously to another commenter here, the .NET Core Frameworks appear to be known more for what they don't have than what they do. Dropping WCF, for example, was a huge blow to those who have invested heavily in actual, quality n-tiered architectural designs; similar to what happened with SilverLight. Microsoft's reaction was simply tell people to use Google's gRPC API. Later the CoreWCF Group would make their first release. And it appears that it is only recently that this new version of CoreWCF has come up to speed as a full featured substitute for the original WCF. My biggest peeve has been the dropping of ASP.NET WebForms (which I worked extensively with for years). Yes, I know all the issues surrounding this web development environment. However, for the most part they were personal preferences in terms of performance (which ASP.NET Core has not shown itself to be significantly faster since it is based upon the ASP.NET MVC standard and engineers have demonstrated this slim advantage to .NET Core... In addition, web performance has always been and always will be predicated on hardware.) For years Microsoft promoted the "thin client" model for n-tiered architectural design. What happened? Did quality system design suddenly disappear into the ether? Yet, the new Blazor environment until very recently has been primarily based upon the "fat client" model, which was initially promoted with ASP.NET MVC. The result is a horde of web applications predicated primarily on JavaScript and an infrastructure that is so complex and ever changing that today many web developers re finding such development a nightmare. ASP.NET WebForms was designed with very good compartmentalization but so many developers misused the "CodeBehind" tier that many such applications became bloated messes. Instead of continuing to refine the internals for WebForms, which Microsoft was in the process of doing in any event, and then telling developers to get with the program in using WebForms in the way it was designed to be used, Microsoft, instead, throws the "baby out with the bathwater" and we get what have today, a bigger mess than we had before. What is interesting to note is that Blazor actually can be used similar to WebForms but it took me a very long time to unearth this feature of Blazor. If one were to use an actual Blazor component and add an @ref attribute to the component's definition, Signal-R will then make the entire component's structure and values available in a manually made equivalent of a WebForms, CodeBehind module. I have started to develop a workbench to test out this style of Blazor development. And so far, so good. If this works throughout my testing, this would mean that I could eliminate JavaScript or Client-Side C# (which is vulnerable to hacking in any event, and just pass the structures back to the middle-tier. However, there is no real documentation that I have come across that explains this very useful feature as it appears that Microsoft wants everyone to use ASP.NET Core in a very specific way, which to me is like the new math being taught in public schools... something that is driving all the students bat-shit crazy and up a wall. As a result, when it comes to whether Jiri should drop support for the original .NET Frameworks, I would say, as I have said earlier, why even make this a thing? Keep the provider for the original .NET Frameworks intact and move on to a separate and new provider for the .NET Core Frameworks. Let the original provider merely be supported for when issues are discovered and require enhancements. However, how many such issues would we expect? Not many since it has been used for quite sometime and should be relatively mature by now just like the frameworks it is supporting... Steve Naidamast |
Also, many Microsoft packages have been issuing warnings like If you want to move away from some versions of .NET Core, I would say ".NET6 or later". |
|
I can't talk about .NET Framework 4.8 but judging by the conversations in this thread, it seems like it might be a sensitive topic 😅. Perhaps you could consider releasing a "last" 10.x version that supports it before discontinuing support in 11.0? My $0.02. |
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?
The text was updated successfully, but these errors were encountered: