Closed majkinetor closed 2 years ago
I'm thinking in switching to .NET Core. I just haven't really studied about it. Mainly what would be the impact on the current codebase, what user would need to do in order to run the app, etc.
Well that is really the only way to go in the not so distant future.
what user would need to do in order to run the app,
That is finally legit in core, since it can have systemic framework, local framework (in app dir), you can compile it into exe or even cherry pick assemblies you want etc..
futre prospects on cross platformness
This is all moot if you don't have a choice, but the notion/promise that a cross-platform .NET is just around the corner has been around for at least a decade. I am very glad to be wrong about this but I wouldn't drop your current effort for the ability to run on Mac/Linux/etc.
Lets keep it civil.
I understand that I'll have to switch to .NET "Core" in the future. Since .NET Framework 4.8 is the "last one". What I don't know is if they are going to enable some sort of cross platform UI.
If not (and if I want to distribute the app to macOS and Linux), I'll have to resort to Xamarin (Native UI + NetStandard lib).
Just a small note: as someone who's had to look at .Net Core for work in the last year, the issue is indeed still that there's no GUI library packaged with Core, and we weren't able to find a good OSS one to use. So, I can lend some support to that likely being the biggest hurdle in this effort.
As an additional aside, as someone who's fulltime Linux, I recognize we're a pretty small chunk of users. That said, this is the only application I miss from Windows. <3
Lets keep it civil
Sure. Not sure what was not civil tho.
What I don't know is if they are going to enable some sort of cross platform UI.
Ofc they will. There is one now already, Avalonia which was even used initially in pwsh's Out-GridView
. But that is irrelevant. Just switching to core has huge performance, methodology, testing and other beneffits, and provides bunch of new options on any front. It will be much easier for random guy to try to make x-platform solution on core, once it works on core in non-platform-GUI way (i.e. wpf on core 3)
Here is a guide for WPF .NetFramework to .NetCore:
https://docs.microsoft.com/en-us/dotnet/desktop-wpf/migration/convert-project-from-net-framework
I'm the writer of Greenshot, and just wanted to give you my opinion:
If you ever have any dotnet core 3.1 specific questions for desktop applications just let me know.
Maybe wait for .NET 5?
@mabakay Yes, I'm waiting for .NET 5
.NET 5, RC1 is here, means API is stable and only bug fixes before final release...!
I had a go at this and got it to build with minor changes, but there where some issues at runtime. BeginInvoke on delegate is not supported in the core runtime and will throw PlatformNotSupportedException.
The size of the published exe got pretty big (as @Lakritzator expected). Using self-contained executable targeting 3.1 resulted in a ~160 MB exe (~150 MB after trimming).
@DarkOoze Have you tried to use .NET 5? What about a non self-contained build?
NET5 trimmed it down to ~90MB but there is missing runtime as it crash on startup. Have not analyzed what is missing.
BeginInvoke is still an issue. It is deprecated and will not come to Core.
Framework-dependent is ~6MB, but not sure how to handle the dependency. ClickOnce might be an option?
The source of the build: https://github.com/DarkOoze/ScreenToGif/tree/dotnet-core
BeginInvoke is still an issue. It is deprecated and will not come to Core.
I believe most of the calls can be easily replaced by await
.
Framework-dependent is ~6MB, but not sure how to handle the dependency.
Perhaps the same way as today with .NET Framework 4.8? I hope that .NET 5 starts to get distributed with Windows too. But in case no dependency is found, a message should appear.
I hope that .NET 5 starts to get distributed with Windows too.
It won't be included in Windows. ¹
I agree with majkinetor that 1 step must be switch to core. Simple because it's .net future.
It's only a "must be" if you want new features. .NET Framework will stay in Windows and will receive security and bug fixes but it won't be developed anymore.
cross platform UI try http://avaloniaui.net/
Its probably better to wait for official one: https://devblogs.microsoft.com/xamarin/the-new-net-multi-platform-app-ui-maui/
When moving to .NET 5 (or 6) this also opens the door for a lot of performance improvements.
I'm aware that there my be bigger concerns, but as a impatient person it would be nice to half down the time needed to save a recording 😃
I only had a quick look into the code-base, and saw that the potential is huge. With .NET 4.8 it doesn't make a lot of sense to continue perf-improvements, but I'd like to help out when switched to .NET 5+. (If there's any interest, then just ping me.)
@gfoidl I'm currently working on improving the capture methods, and I should start working on changes for +NET5 shortly afterwards (weekend).
If you would like to help, that would be nice. :)
.net MAUI not support Win7 , sadly :(
.net MAUI not support Win7 , sadly :(
And linux. Imho avalonia is the choise in terms of cross platform UI and also it's has WPF roots.
I'm working on this task now.
For those who tried converting the project to .NET 5:
Did you use the upgrade assistant to upgrade to .NET 5? What did you do with the App.config? Is there a replacement for IpcChannel?
Is there a replacement for IpcChannel?
No... but yes? https://docs.microsoft.com/en-us/dotnet/core/porting/net-framework-tech-unavailable#remoting
I can't create mutexes with a specific security detail:
var sec = new MutexSecurity();
sec.AddAccessRule(new MutexAccessRule(Environment.UserDomainName + "\\" + Environment.UserName, MutexRights.FullControl, AccessControlType.Allow));
var mutex = new Mutex(false, @"Global\ScreenToGif" + key.Remove("\\"), out bool created, sec);
When moving to .NET 5 (or 6) this also opens the door for a lot of performance improvements.
If someone says that he needs new framework for do any real performance optimization I am little sceptic. Performance optimizations are made by using the profiler not by changing code with synthetic sugar from newer compiler ;-)
@NickeManarin
Did you use the upgrade assistant to upgrade to .NET 5?
From our experience it's ok for simple project and bad for complex (for example with many native x86/x64 libraries). And any way your need manual tuning after.
What did you do with the App.config?
We ended up giving it up.
Is there a replacement for IpcChannel?
I think you already know the answer :)
I can't create mutexes with a specific security detail:
var sec = new MutexSecurity(); sec.AddAccessRule(new MutexAccessRule(Environment.UserDomainName + "\\" + Environment.UserName, MutexRights.FullControl, AccessControlType.Allow)); var mutex = new Mutex(false, @"Global\ScreenToGif" + key.Remove("\\"), out bool created, sec);
You need to use ThreadingAclExtensions and do like this:
var mutex = new Mutex(false, @"Global\ScreenToGif" + key.Remove("\\"), out bool created);
var sec = new MutexSecurity();
sec.AddAccessRule(new MutexAccessRule(Environment.UserDomainName + "\\" + Environment.UserName, MutexRights.FullControl, AccessControlType.Allow));
mutex.SetAccessControl(sec);
If someone says that he needs new framework for do any real performance optimization I am little sceptic. Performance optimizations are made by using the profiler not by changing code with synthetic sugar from newer compiler ;-)
What if the framework provides new capabilities to use? What if the framework itself got faster and we use that work as grounding for this work? (And of course I had a look through profilers to see what's going on).
Is there a replacement for IpcChannel?
I replaced it with JSON over a named pipe. https://github.com/NickeManarin/ScreenToGif/commit/c267f1a5bf75fd274da743eb8872feff49166c02
Thanks @kirsan31 and @DarkOoze for the code samples.
Hmm... I simply removed these three assemblies, no issues so far.
I'm simply replacing all BeginInvoke()
calls with await Task.Run()
to make it work, but the idea is to revise everything.
Specially the Editor, Webcam and Board recorders, which are going to be reworked.
Publishing as a single executable with no loose dll's in the folder is my target too.
Using this command over my base takes a long time and generates a 104MB executable which does not work...
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true /p:PublishTrimmed=true /p:IncludeNativeLibrariesForSelfExtract=true
Could be related to this:
.\ScreenToGif\ScreenToGif\Util\ProcessHelper.cs(14,84): warning IL3000:
'System.Reflection.AssemblyName.CodeBase' always returns an empty string for assemblies embedded in a single-file app.
If the path to the app directory is needed, consider calling 'System.AppContext.BaseDirectory'.
[.\ScreenToGif\ScreenToGif\ScreenToGif.csproj]
@NickeManarin I don't know about wpf, but trimming in WinForms have many many problems (if work at all).
Yeah, that's it.
Size goes to 176MB but it works.
I hope there will be an option to download framework dependent release 🤣
I would like some help with testing the branch feature/579 or the binaries bellow.
BTW: According to NET's development roadmap, it seems GA for odd number version, while even for LTS since NET 5.0, So maybe You can wait for NET 6's coming but prepare based on .NET 5.0. I'd like to say "Waiting for your version based on NET 6 (or future) even number LTS version.
For more, you can refer to : https://dotnet.microsoft.com/platform/support/policy/dotnet-core
I would like some help with testing the branch feature/579 or the binaries bellow.
At first look both .Net5 and .Net6 versions works fine. Win10 20H2.
I would like some help with testing the branch feature/579 or the binaries bellow.
The quick test went smoothly. Win10 1909 x64.
I just merged the branch with the migration for .NET 6.
I just merged the branch with the migration for .NET 6.
Is it going to be merged to master? For now all commits are in feature/579-migrate-to-net6 branch..
@bairog After the release. During development, the dev branch is used instead.
Hey and what with performance? Is the application already faster because of running under .NET 6 runtime?
Hey and what with performance? Is the application already faster because of running under .NET 6 runtime?
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core/ https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-2-1/ https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/ https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/ https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/
Cross platformness is something that was asked number of times here.
Now, .Net Framework 4.6 is dead and .NET Core is where all the things will happen. Migrating to it would be great for both maintainabilaty and futre prospects on cross platformness. For example, v3 added WPF (for Windows only currently).
This will make it much easier to achieve Linux/Mac port in the future - maybe WPF will become x-platform itself, or it can be switched to something else like Avalon or whatever... There is also option to use wine with WPF on linux.
So, switching to net core provides a lot of more options, and it must be done sooner or later anyway.