mirror of
https://github.com/NickeManarin/ScreenToGif.git
synced 2026-04-25 23:25:52 +03:00
[GH-ISSUE #1209] Don't require .NET 6 #897
Labels
No labels
copy cats
duplicated
future feature
pull-request
⬜ Accepted
⬜ Completed
⬜ Help Wanted 💪
⬜ In Progress
⬜ Missing Details
⬜ Pending
⬜ Waiting For Answer ⏳
🆕 feature preview
🔷 Bug 🐛
🔷 Out Of Scope
🔷 Out Of Scope
🔷 Question
🔷Enhancement
🔷Enhancement
🔷Invalid / External
🔷Knowledge Base
🔷Won't Fix
🕑 High
🕑 High
🕑 High
🕕 Medium
🕙 Low
🕛 Critical
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ScreenToGif#897
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @thany on GitHub (Jun 27, 2023).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1209
Originally assigned to: @NickeManarin on GitHub.
Describe the bug
Make it backwards compatible with .NET 5, which is shipped with every modern OS. Don't require to install a huge framework, especially since on developer machines it might very well interface with application being built on .NET 5.
Expected behavior
Works with .NET 5 and 6, whichever version is installed.
Desktop (please complete the following information):
Additional context
Embedding .NET 6 in the portable version is crude and makes it absolutely massive. Don't do that. Actually fix the problem please. .NET is not as safely upgradable as Java is.
@tats-u commented on GitHub (Jul 2, 2023):
.NET 5 has been EOL since more than 1 years ago.
Also many latest C# features require latest .NET runtime or https://github.com/Sergio0694/PolySharp.
.NET forces us to update every LTS versions.
@thany commented on GitHub (Jul 4, 2023):
.NET 4 is still in regular use, so I dunno. The point is, don't require users to install (or require yourself to bundle) a framework, when another super heavy bulky version is already installed on the system. Just use whatever the OS comes with, I'm sure it's perfectly capable as proven by 2.35.4.
@tats-u commented on GitHub (Jul 4, 2023):
@thany There's no .NET 4. Do you refer to .NET Framework 4.x? They are too stale like zombies and Java 8. They are different from .NET Core 1-3 and .NET 5+. We can't use C# 8+ features out of the box including null-safe reference types (it's disabled by default in this project though). Also they lack some convenient APIs.
I'm preparing a pull request that shouldn't work in them.
From the order of project templates in the latest Visual Studio (.NET 6/7 templates come before .NET Framework ones), Microsoft doesn't seem to recommend .NET Framework for new projects anymore.
As for the bundling of runtimes, I'll wait for an author's reply. I haven't ever been asked to install the desktop runtime of .NET 6 though.
@thany commented on GitHub (Jul 5, 2023):
I don't know, I don't keep tracking of the 17 billion versions of .NET (Core, Framework, or whatever) and what is a zombie and what isn't.
Again, the point is, don't require users to install an additional framework, when a perfectly good one is already installed (and indeed shipped with Windows). Only on an older version of Windows, a .NET install might be justifyable.
I frankly don't care about the reasoning behind it. As a user, I'm annoyed when I download a few megabytes of a program, and then am required to install hundreds of megabytes more, for a framework that (again) might interfere with whatever else I might be running. I'm just simply not going to do that. And yes, bundling the framework is a solution, but a terrible one at that.
@tats-u commented on GitHub (Jul 5, 2023):
https://github.com/dotnet/core/issues/6411#issuecomment-868813991
It seems MS won't bundle .NET 6+ by default.
In your words, don't require developers to downgrade to the stale framework not recommended these days by MS HQ. Even migration from .NET Framework to .NET 6 is not easy. It can take more than an year for larger enterprise applications than this software. I'm not a maintainer of this application, but have to reduce the number of people who believe .NET Framework is sufficient and doesn't have to be retired just yet. .NET 6 has better performance than .NET Framework.
https://devblogs.microsoft.com/dotnet/microsoft-teams-assignments-service-dotnet-6-journey/
I measured the size in the folder
C:\Program Files\ScreenToGif(installer version). You said hundreds of MB but actually it was just 167MB. This is smaller than Git (370MB), GIMP (1.78GB), iTunes (412MB), Wireshark (202MB), Firefox (220MB), and draw.io desktop app (414MB).I will never say this is "perfectly good". This is pre-installed just for backward-compatibility like the ancient VB6 runtime (the support for its development tools has already been expired). No new features except for the native support for ARM are added since 2019. Only security and bug fixes are provided.
https://github.com/NickeManarin/ScreenToGif/releases/tag/2.38.1
@NickeManarin Does
Light.Portablenot contain .NET 6 runtime and require us to install it?@thany commented on GitHub (Jul 6, 2023):
For the installed entire framework. When bundled, it's """only""" 167MB for a program that can be under 14MB.
And it doesn't matter if it's smaller than other popular programs. That's whataboutism. Compare it to STG previous version: you'll agree that the portable version has ballooned to well over 10x its size, because .NET needs to be bundled.
Firefox is 220MB for very good reasons. It can do SO MUCH MORE, but the same rule would apply: if Firefox would blow up to 2.2GB, some folks might accept it, but certainly no one would appreciate it.
GIMP and Wireshark are big because they have to include or embed the Qt framework. At least for Qt there's no preinstalled version available on Windows, so I accept that. Git is big because it includes mingw64, which shouldn't be neccesary and I think it can be left out. But it's there. At least the executable isn't 370MB, right?
Other big applications might be that way because they are web-based, like VScode or Postman or Draw.io. Sure, they could use the preinstalled Edge, but they don't. I don't quite agree with that either, but at least in those cases, the programs themselves don't make the decisions directly to include a whole Chromium runtime - that's how Electron works.
In the case of STG, it uses .NET directly - not through some library/framework. STG's authors have made the conscious and deliberate decision to go for a framework that has to be priorly installed (or bundled) pretty much everywhere. And THAT is the problem. It was a deliberate decision to go this way. And what does the user gain from it? Nothing. STG 2.35 (14MB) works perfectly. Going over to a new .NET version is purely developer experience. And for the supposed convenience of the developers, we now have to deal with either installing yet another bulky framework that, again, might interfere with other stuff running on whatever the current .NET framework is, or we have to swallow a humongous bundled version.
@tats-u commented on GitHub (Jul 6, 2023):
Don't count on the .NET Framework, as dim as old guys. The reason Microsoft keeps building it into Windows is a similar reason you don't kill your elderly parents just because they're retired and need care. The backward compatibility of Windows is phenomenal, but we should not be complacent about it.
Versions of it vary from computer to computer. Some install 4.8 but some 4.6 or earlier due to compatibility concerns (4.8 should work though).
If ScreenToGif targeted at 4.8? Those that install 4.6 can't run ScreenToGif. How unsound it is.
I don' agree with your reason why you discriminate .NET from Qt and Chromium.
Don't be picky with a capacity that's only several thousandths of SSD. You should be the first to complain to Microsoft, not authors of individual software. As we see there're so many apps much larger than ScreenToGif.
ScreentToGif itself without .NET is 21MB according to
Light.Portable. In the first place, Windows, unlike Unix, doesn't have much of a habit of sharing libraries with multiple pieces of software.If the problem you describe is serious enough, Microsoft will do something about it.
@thany commented on GitHub (Jul 6, 2023):
I don't count on it. Microsoft is both famous for its phenomenal backwards compatibility in certain areas, and infamous for the lack thereof in other areas. Installing a newer version of .NET always leads to problems with other stuffing depending on it. Always.
4.6 then, what do I care? Whatever is shipped with Windows 10 and up. And AGAIN, it worked fine in STG 2.35, so why even change over to a new version in the first place?
We'll agree to disagree then. If you don't mind installing a whole framework for each and every application, good for you. But it's not normal to be required to do so.
Here we go again. Sure ONE application being a little on the larger side is fine. But I don't have one application, and every application author thinks it's fine, because everyone has hundreds of terabytes anyway, right?
Similarly, throwing ONE plastic bottle in the ocean is fine, but there are millions, because everyone thinks "just one more" is acceptable. It's not.
To summarise: don't just grab all the storage you think you can get away with, just because it's available. Don't waste resources.
Oh? .NET is our prime example. DirectX, OpenGL, everything behind Modern Apps? You know very well .NET is shared, don't kid yourself. All you have to do is use it, and not require a different version just because you wanna do it differently for whatever reason.
In the end, the light portable version doesn't work, and the heavy portable one is too big. That's all. Why, how, when, where, what, I don't actually care about any of that as long as I'm wearing the proverbial hat of a user. The current situation is not acceptable, and I'm forced to stick with the previous release. That's all. You can talk about it long and short, but the fact remains that the newest version is not usable.
@NickeManarin commented on GitHub (Jul 6, 2023):
This discussing is pointless.
The app won’t target an older, slower and worse to develop for framework to appease to an illusion of saving 100MB’s.
You installed NET framework 4.8, 4.7 or what ever version before, as it came with Windows or by manually installing.
Do the same with NET 6 and then just download the light version and you should be fine.
Now, if you want to complain about something, go to Microsoft and complain about their new policy for not shipping NET +5 with Windows or complain about NET existing in the first place.
Remember that this is a free and open source software. Peace out.
@tats-u commented on GitHub (Jul 6, 2023):
@NickeManarin Sorry for messing here up. As someone who is fed up with the presence of the .NET Framework, I couldn't leave it alone.
@thany commented on GitHub (Jul 7, 2023):
I didn't, not on purpose anyway.
I will not repeat myself again if you not only fail, but straight up refuse to understand my point.
That is not really an excuse for anything. I'm trying to be reasonable towards making the software better for everyone, not just the developer. If you cannot fathom the issue at hand, then 2.36 and up is considered broken and unusable. The latest working version is 2.35.4, for mostly everyone except those who have yielded.
If you think the discussion is pointless, that says more about you than it does about me. Cheers!