3 ms·

> too few selling points There are significant performance improvements, and the new language features of C# depend on the later versions - that might not be s

by louthy 4y ago

> too few selling points There are significant performance improvements, and the new language features of C# depend on the later versions - that might not be such a big deal, but it will become more acute as the language improves.

ok123456 4y ago
You can get most of the new language features to work with .Net Framework by overriding the LanguageVersion in the build. I did this to get nullable type annotations and pattern matching to work when I inherited a .Net Disaster. There are a few that require compiler interop which don't work, like using new syntax on records for specifying the fields (e.g., "record A(int a, int b)").
- louthy 4y ago
  Not all, some rely on the runtime, like static interface methods. Records can be enabled like this [1] [1] https://github.com/louthy/language-ext/blob/main/LanguageExt.Core/IsExternalInit.cs https://github.com/louthy/language-ext/blob/main/LanguageExt...
  - ok123456 4y ago
    I found that, but I didn't want to introduce more complexity into the build by requiring those same stubs be defined for just a slight advantage.
- deleted 4y ago
  [deleted]
WorldMaker 4y ago
Also, proper High DPI support in both WinForms and WPF in .NET 5+. There is starting to be a very notable difference there between applications compiled on .NET Framework (or VB6) versus those recompiled for .NET 5+ WinForms/WPF with older apps not just looking dated, but sometimes aggravatingly unusable/inaccessible on modern monitors.
- int_19h 4y ago
  I don't think I've ever seen a WPF app broken on hi-DPI, and I use a 4K display with 225% scaling. It was designed from grounds up as resolution-independent.
  - WorldMaker 4y ago
    WPF does in general have many fewer issues than WinForms and the ones I've seen that were basically just broken were all WinForms. There's still some changes to WPF that are noticeable if you are looking for them (mostly in the default controls).

by louthy 4y ago

ok123456 4y ago

You can get most of the new language features to work with .Net Framework by overriding the LanguageVersion in the build. I did this to get nullable type annotations and pattern matching to work when I inherited a .Net Disaster. There are a few that require compiler interop which don't work, like using new syntax on records for specifying the fields (e.g., "record A(int a, int b)").

louthy 4y ago
Not all, some rely on the runtime, like static interface methods. Records can be enabled like this [1] [1] https://github.com/louthy/language-ext/blob/main/LanguageExt.Core/IsExternalInit.cs https://github.com/louthy/language-ext/blob/main/LanguageExt...
- ok123456 4y ago
  I found that, but I didn't want to introduce more complexity into the build by requiring those same stubs be defined for just a slight advantage.
deleted 4y ago
[deleted]

WorldMaker 4y ago

Also, proper High DPI support in both WinForms and WPF in .NET 5+. There is starting to be a very notable difference there between applications compiled on .NET Framework (or VB6) versus those recompiled for .NET 5+ WinForms/WPF with older apps not just looking dated, but sometimes aggravatingly unusable/inaccessible on modern monitors.

int_19h 4y ago
I don't think I've ever seen a WPF app broken on hi-DPI, and I use a 4K display with 225% scaling. It was designed from grounds up as resolution-independent.
- WorldMaker 4y ago
  WPF does in general have many fewer issues than WinForms and the ones I've seen that were basically just broken were all WinForms. There's still some changes to WPF that are noticeable if you are looking for them (mostly in the default controls).