Sharing this here in case anyone is interested:
CODE Magazine State of .NET webinar, “Windows Desktop
Development in .NET 5”.
Join Us Wednesday, February 24 @ 1:00pm EST
Save Wednesday, February 24th @ 1:00pm Eastern / 12:00pm Central / 10:00am
Pacific for our next CODE Magazine State of .NET webinar, “Windows Desktop
Development in .NET 5”. Join Markus Egger (President & Chief Software
Architect of EPS Software / CODE Consulting and Microsoft Regional
Director) as he reviews the options available for building Windows desktop
applications with .NET 5.
Markus will answer as many of your questions as possible. We're trying to
help educate as many developers as possible so please share this info with
your developer friends. Thanks!
Do you build or maintain Windows deskop applications? Tell us about it at
info@codemag.com
<info@codemag.com?subject=What%20we%20use%20for%20Windows%20desktop%20development...>
.
State of .NET - Windows Desktop Development in .NET 5
*February 24, 2021 - Wednesday Start time: 1:00pm Eastern / 12:00pm Central
Duration: 75 minutes (60 minute presentation, 15 minute Q&A)*
We've created a series of State of .NET online events each focusing on a
specific .NET topic. This installment covers *Windows Desktop Development
With .NET 5*. While topics such as Blazor or Azure may be getting a lot
more attention, Windows Desktop development is still a very important
topic. Not just that, but with technologies such as WinUI, MAUI, and
others, there is a lot of movement in this segment of .NET development.
Join Markus Egger to take a close look at what you need to know to make the
right decisions for your path forward.
Topics covered in this event include:
- WinForms - in .NET 4.x and .NET 5
- Windows Presentation Foundation (WPF) - in .NET 4.x and .NET 5
- Xamarin Forms and MAUI
- WinUI and Fluid UI
- Electron and Photino
- and more…
*Note*: Only registered attendees will receive the live stream URL the
morning of the event via email.
Click here
<https://u14306485.ct.sendgrid.net/ls/cl ... 7O8Kz0I-3D>
for more information about this webinar.
*Click Here to Register for FREE!
<https://u14306485.ct.sendgrid.net/ls/cl ... 488q8Ss-3D>*
Seminar - The state of desktop app development in .Net 5
Seminar - The state of desktop app development in .Net 5
Hi Matt,
thank you very much - I have registered now.
For Middle Europe, this is 19:00 (or 7:00 PM), if my calculation is right.
Wolfgang
thank you very much - I have registered now.
For Middle Europe, this is 19:00 (or 7:00 PM), if my calculation is right.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Seminar - The state of desktop app development in .Net 5
Thanks for bringing this to our attention. I have just watched the presentation of Markus Egger. Interesting for sure!
A few remarks:
1 .Net5 seems to have a significant speed issue. He was having a coffee waiting for some stuff to finalize. And the word "usual" in his explanation "it is usual only slow the first time" was not encouraging.
2 I wonder why the folder browser control gets worse with newer technologies? The Win32 had an autocomplete textbox + a visual informative disk/directory view. Nothing like that in WPF, and Markus showed that going from .Net 4.x to .Net5 the browser converts to a FolderDialog which, as I noted with my software, confuses users as they expect files to display. I implemented it and a user of my photo software asked me why he didn't see any pictures? Turned out that using the folder browser (I programmed that exactly as he showed it to work in .Net5) was the cause, he expected files to appear there despite the clear Select folder button.
Finally I offered in my WPF project a combination of an Open button using System.Windows.Forms.FolderBrowserDialog (without the Win32 option to type & autocomplete a directory). For that I have inserted a Winforms Textbox where you can assign that behavior in WPF with )in the XAML) a simple:
wf:TextBox x:Name="ImagesDir" AutoCompleteMode="SuggestAppend
Probably that was all required because Microsoft stopped investing much in WPF as he explained.....
I think I am not hurrying to .Net5. It is probably neglected soon as well judging from the poor implementation of something like a directory browser.
Dick
A few remarks:
1 .Net5 seems to have a significant speed issue. He was having a coffee waiting for some stuff to finalize. And the word "usual" in his explanation "it is usual only slow the first time" was not encouraging.
2 I wonder why the folder browser control gets worse with newer technologies? The Win32 had an autocomplete textbox + a visual informative disk/directory view. Nothing like that in WPF, and Markus showed that going from .Net 4.x to .Net5 the browser converts to a FolderDialog which, as I noted with my software, confuses users as they expect files to display. I implemented it and a user of my photo software asked me why he didn't see any pictures? Turned out that using the folder browser (I programmed that exactly as he showed it to work in .Net5) was the cause, he expected files to appear there despite the clear Select folder button.
Finally I offered in my WPF project a combination of an Open button using System.Windows.Forms.FolderBrowserDialog (without the Win32 option to type & autocomplete a directory). For that I have inserted a Winforms Textbox where you can assign that behavior in WPF with )in the XAML) a simple:
wf:TextBox x:Name="ImagesDir" AutoCompleteMode="SuggestAppend
Probably that was all required because Microsoft stopped investing much in WPF as he explained.....
I think I am not hurrying to .Net5. It is probably neglected soon as well judging from the poor implementation of something like a directory browser.
Dick
Seminar - The state of desktop app development in .Net 5
Hi Dick
Unfortunately I have not seen the .Net5 presentation and although I would not suggest you or anyone else with commercial pressures to contend with “hurry” to .Net5, I am a little surprised at some of the conclusions you came to.
The fact is that the functionality of your program in “Netted” code is encapsulated totally within your program code and nowhere else. This is not the case for programs written in non-netted code.
This difference is very significant in many ways.
For example, in non-netted code the functionality required by the generation of an interrupt (hardware generated) necessitates code structures out-with program code, namely operating system code.
The fact is that .Net5 is perfectly usable now, projects can be developed using the latest syntax (short-cuts) of C#9 and the potential for developing high-performance code (largely from optimizations of your own code) exists. This will require understanding of statistics and time to assimilate things, so now is a good time to try it all out.
WPF is, and my guess will continue to be, available. I can quite believe that MS stopped investing in WPF, but that is because it’s gone as far as it needs anyway.
Just my take on things.
best Regards
Terry
Unfortunately I have not seen the .Net5 presentation and although I would not suggest you or anyone else with commercial pressures to contend with “hurry” to .Net5, I am a little surprised at some of the conclusions you came to.
The fact is that the functionality of your program in “Netted” code is encapsulated totally within your program code and nowhere else. This is not the case for programs written in non-netted code.
This difference is very significant in many ways.
For example, in non-netted code the functionality required by the generation of an interrupt (hardware generated) necessitates code structures out-with program code, namely operating system code.
The fact is that .Net5 is perfectly usable now, projects can be developed using the latest syntax (short-cuts) of C#9 and the potential for developing high-performance code (largely from optimizations of your own code) exists. This will require understanding of statistics and time to assimilate things, so now is a good time to try it all out.
WPF is, and my guess will continue to be, available. I can quite believe that MS stopped investing in WPF, but that is because it’s gone as far as it needs anyway.
Just my take on things.
best Regards
Terry
Seminar - The state of desktop app development in .Net 5
Hello Terry,
You can still see the webinar via https://www.youtube.com/watch?v=s45HDmkTKKg.
About the speed: on 46:58 Markus starts a very basic (.Net5 converted) Winforms program with 2 controls on it. It takes until 47:38 before it starts. On 47:30 he says "Boy, this is really taking long". And that he says that it's "usually" only slow the first time is not encouraging. But as this is a basic demo program; the original .Net 4.0 version of it started on 43:47 and is up and running on 43:55. Still much slower than a VO Win32 would take.
I see the same with Winforms and WPF. The 2 Winforms controls on my WPF application appear 1-2 seconds earlier than the WPF controls. It looks like with every new development, Microsoft stuff is getting slower and or less usable after having introduced some nice new technology, as for WPF the XAML full codeable windows are.
I directly admit that this is all I saw from .Net5 but the general direction Microsoft is moving in has been the same for years: 1 step forward, 2 backwards.
Finally around 56:53 Markus talks about WPF and a bit later on he says (remember he is a MS executive as well) that Microsoft has not assigned enough resources to WPF but that there's still a chance that this will change.
And no, WPF has not gone as far as it needs to be. There's a lot which cries for enhancement. Unless they would have announced that it would become "legacy" (like the Windows Phone). There's a roadmap:
https://github.com/dotnet/wpf/blob/master/roadmap.md
See also:
https://docs.microsoft.com/en-us/answer ... r-uwp.html
where one of the contributors writes "There's a long way to go until it is complete" on which I totally agree
or this:
https://visualstudiomagazine.com/articl ... urvey.aspx (note the large % of voters being extremely and moderately dissatisfied with WPF).
Dick
You can still see the webinar via https://www.youtube.com/watch?v=s45HDmkTKKg.
About the speed: on 46:58 Markus starts a very basic (.Net5 converted) Winforms program with 2 controls on it. It takes until 47:38 before it starts. On 47:30 he says "Boy, this is really taking long". And that he says that it's "usually" only slow the first time is not encouraging. But as this is a basic demo program; the original .Net 4.0 version of it started on 43:47 and is up and running on 43:55. Still much slower than a VO Win32 would take.
I see the same with Winforms and WPF. The 2 Winforms controls on my WPF application appear 1-2 seconds earlier than the WPF controls. It looks like with every new development, Microsoft stuff is getting slower and or less usable after having introduced some nice new technology, as for WPF the XAML full codeable windows are.
I directly admit that this is all I saw from .Net5 but the general direction Microsoft is moving in has been the same for years: 1 step forward, 2 backwards.
Finally around 56:53 Markus talks about WPF and a bit later on he says (remember he is a MS executive as well) that Microsoft has not assigned enough resources to WPF but that there's still a chance that this will change.
And no, WPF has not gone as far as it needs to be. There's a lot which cries for enhancement. Unless they would have announced that it would become "legacy" (like the Windows Phone). There's a roadmap:
https://github.com/dotnet/wpf/blob/master/roadmap.md
See also:
https://docs.microsoft.com/en-us/answer ... r-uwp.html
where one of the contributors writes "There's a long way to go until it is complete" on which I totally agree
or this:
https://visualstudiomagazine.com/articl ... urvey.aspx (note the large % of voters being extremely and moderately dissatisfied with WPF).
Dick
Seminar - The state of desktop app development in .Net 5
Hi Dick,
let me say something about WPF: you are right, WPF is not yet finished and I think it will never at that point, but since there are a lot of 3rd party producers there is no pressure for Microsoft to invest time and money.
And I had a confirmation that the visual designers for WPF don't work - so I don't miss anything when writing my WPF windows completely in code using XIDE.
It is clear that WPF will always be slower than WinForms because it is a complete different approach, but it is also much, much more flexible.
Wolfgang
let me say something about WPF: you are right, WPF is not yet finished and I think it will never at that point, but since there are a lot of 3rd party producers there is no pressure for Microsoft to invest time and money.
And I had a confirmation that the visual designers for WPF don't work - so I don't miss anything when writing my WPF windows completely in code using XIDE.
It is clear that WPF will always be slower than WinForms because it is a complete different approach, but it is also much, much more flexible.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Seminar - The state of desktop app development in .Net 5
Hi Wolfgang,
Do you mean that VS will not have visual designers for WPF for the new framework versions? Well, that would be really funny to implement a WPF editor in XIDE for them now
Do you mean that VS will not have visual designers for WPF for the new framework versions? Well, that would be really funny to implement a WPF editor in XIDE for them now
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Seminar - The state of desktop app development in .Net 5
Hello Chris and Wolfgang,
The VS designer for WPF works - more or less. But it's often impossible, on more elaborate windows, to get a control where you expect it. Probably that is (partly) because of WPF elements like a StackPanel or a WrapPanel which determine how controls are placed. But also there are clear omissions, e.g. I have Ribbon but in the designer I only can select (as far as I know) the elements of the first tab.
I am sure if you could do a better job Chris, but I am not sure if you can do that in a reasonable time :unsure: ; I can imagine it is a lot of work.
And yes Wolfgang, I realize that WPF is something different than Winforms but this is exactly what I mean: 1 step forward is that it's more flexible, 2 steps back means that the Designer is less usable and the building of the screen takes more time. It would be great when Microsoft would for once release something that doesn't have (potentially) more drawbacks than advantages.
Dick
Dick
The VS designer for WPF works - more or less. But it's often impossible, on more elaborate windows, to get a control where you expect it. Probably that is (partly) because of WPF elements like a StackPanel or a WrapPanel which determine how controls are placed. But also there are clear omissions, e.g. I have Ribbon but in the designer I only can select (as far as I know) the elements of the first tab.
I am sure if you could do a better job Chris, but I am not sure if you can do that in a reasonable time :unsure: ; I can imagine it is a lot of work.
And yes Wolfgang, I realize that WPF is something different than Winforms but this is exactly what I mean: 1 step forward is that it's more flexible, 2 steps back means that the Designer is less usable and the building of the screen takes more time. It would be great when Microsoft would for once release something that doesn't have (potentially) more drawbacks than advantages.
Dick
Dick
Seminar - The state of desktop app development in .Net 5
Yeah, I was only joking Dick, it's a lot of work and most importantly it's not "nice" work.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Seminar - The state of desktop app development in .Net 5
Hi Chris,
I mean that the code that the XAML designer writes is unusable.
Too much code, and if you make something wrong, it will not be reversible.
It is much like HTML: so dynamic that a conventional designer will fail.
As I wrote some time ago to you: the only way to build a WPF designer would be a tree formed tool: add elements in the visual tree, and have a preview pane.
Wolfgang
P.S. my customers like the WPF GUI
I mean that the code that the XAML designer writes is unusable.
Too much code, and if you make something wrong, it will not be reversible.
It is much like HTML: so dynamic that a conventional designer will fail.
As I wrote some time ago to you: the only way to build a WPF designer would be a tree formed tool: add elements in the visual tree, and have a preview pane.
Wolfgang
P.S. my customers like the WPF GUI
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it