Use .NET 6 - Githubissues

majkinetor commented 4 years ago

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.

NickeManarin commented 4 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.

majkinetor commented 4 years ago

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..

vatterspun commented 4 years ago

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.

NickeManarin commented 4 years ago

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).

marzhall commented 4 years ago

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

majkinetor commented 4 years ago

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)

NickeManarin commented 4 years ago

Here is a guide for WPF .NetFramework to .NetCore:

https://docs.microsoft.com/en-us/dotnet/desktop-wpf/migration/convert-project-from-net-framework

kirsan31 commented 4 years ago

@NickeManarin this can help a bit with project converting. I agree with @majkinetor that 1 step must be switch to core. Simple because it's .net future. And then, may be (if needed), switch from WPF to Avalonia...

Lakritzator commented 4 years ago

I'm the writer of Greenshot, and just wanted to give you my opinion:

WPF or WinForms just works fine with dotnet core 3.1, minimum changes!
There is currently no x-plat solution for a UI, but this would not be the only challenge you have (capturing the screen, webcam etc)
The biggest issue for Greenshot is the packaging, you cannot assume there is a dotnet core 3.1 runtime installed so you will need to bring this yourself -> blowing up the download size

If you ever have any dotnet core 3.1 specific questions for desktop applications just let me know.

mabakay commented 3 years ago

Maybe wait for .NET 5?

NickeManarin commented 3 years ago

@mabakay Yes, I'm waiting for .NET 5

srbala commented 3 years ago

.NET 5, RC1 is here, means API is stable and only bug fixes before final release...!

DarkOoze commented 3 years ago

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).

NickeManarin commented 3 years ago

@DarkOoze Have you tried to use .NET 5? What about a non self-contained build?

DarkOoze commented 3 years ago

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

NickeManarin commented 3 years ago

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.

catthehacker commented 3 years ago

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.

John0King commented 3 years ago

cross platform UI try http://avaloniaui.net/

majkinetor commented 3 years ago

Its probably better to wait for official one: https://devblogs.microsoft.com/xamarin/the-new-net-multi-platform-app-ui-maui/

gfoidl commented 3 years ago

When moving to .NET 5 (or 6) this also opens the door for a lot of performance improvements.

a lot of (intermediate) allocations could be avoided, so less memory usage and work for the GC
more performant routines provided by the framework can be used for "free" (they don't need to be re-implemented here for .NET 4.8)

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.)

NickeManarin commented 3 years ago

@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. :)

John0King commented 3 years ago

.net MAUI not support Win7 , sadly :(

kirsan31 commented 3 years ago

.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.

NickeManarin commented 3 years ago

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?

NickeManarin commented 3 years ago

Is there a replacement for IpcChannel?

No... but yes? https://docs.microsoft.com/en-us/dotnet/core/porting/net-framework-tech-unavailable#remoting

NickeManarin commented 3 years ago

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);

mabakay commented 3 years ago

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 ;-)

kirsan31 commented 3 years ago

@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);

gfoidl commented 3 years ago

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).

DarkOoze commented 3 years ago

Is there a replacement for IpcChannel?

I replaced it with JSON over a named pipe. https://github.com/NickeManarin/ScreenToGif/commit/c267f1a5bf75fd274da743eb8872feff49166c02

NickeManarin commented 3 years ago

Thanks @kirsan31 and @DarkOoze for the code samples.

NickeManarin commented 3 years ago

Hmm... I simply removed these three assemblies, no issues so far.

NickeManarin commented 3 years ago

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.

NickeManarin commented 3 years ago

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]

kirsan31 commented 3 years ago

@NickeManarin I don't know about wpf, but trimming in WinForms have many many problems (if work at all).

NickeManarin commented 3 years ago

Yeah, that's it.

Size goes to 176MB but it works.

kirsan31 commented 3 years ago

I hope there will be an option to download framework dependent release 🤣

NickeManarin commented 3 years ago

For later: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5

NickeManarin commented 3 years ago

I would like some help with testing the branch feature/579 or the binaries bellow.

x64.zip

SEWeiTung commented 3 years ago

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

kirsan31 commented 3 years ago

I would like some help with testing the branch feature/579 or the binaries bellow.

x64.zip

At first look both .Net5 and .Net6 versions works fine. Win10 20H2.

bairog commented 2 years ago

I would like some help with testing the branch feature/579 or the binaries bellow.

x64.zip

The quick test went smoothly. Win10 1909 x64.

NickeManarin commented 2 years ago

I just merged the branch with the migration for .NET 6.

bairog commented 2 years ago

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..

NickeManarin commented 2 years ago

@bairog After the release. During development, the dev branch is used instead.

mabakay commented 2 years ago

Hey and what with performance? Is the application already faster because of running under .NET 6 runtime?

kirsan31 commented 2 years ago

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/

NickeManarin / ScreenToGif

Use .NET 6 #579