Fellow Csla developers and Desktop apps

[Chicagoan2016]

We have a few Winforms applications. In the past one of the developers tried WPF but he didn't use any MVVM framework and the code (behind the forms) is even 'worse' than Winforms.
What do fellow Csla developers recommend for Desktop development?
We only target windows machines.

Regards

[rockfordlhotka]

I must say @Chicagoan2016, that I've been almost entirely focused on Blazor for quite some time. And combining Blazor with MAUI allows you to create native Windows apps with (what I think is) the best UI framework Microsoft has created thus far.

On the other hand, if you are willing to use "modern" DI concepts with Windows Forms or WPF, those UI frameworks are quite compelling (imo) if you use DI instead of an MVVM framework. The thing about DI is that it replaces at least one of the major reasons for needing an MVVM framework, in that it allows a "page" (form?) to have a constructor that requires a viewmodel as a service. And that viewmodel can instantiate a domain object.

I haven't spent extensive time doing this, but enough that I'm convinced that if a winforms or wpf app were to embrace DI (and CLSA 6+), it would be a pretty nice experience to build a Windows app using DI+CSLA.

All that said, I still think Blazor is too good to ignore, and so I'd explore the Blazor Hybrid (MAUI) idea of creating a Windows-only MAUI Hybrid app.

[Chicagoan2016]

@rockfordlhotka Thank you Sir. One big consideration for our team is the SSRS Reporting services and how we use reports in winforms inside reportviewer control. Do we have something similar for Blazor Hybrid applications?
Regards

[hurcane]

I am presuming that you are using the Winforms report viewer control from Microsoft, and not using an SSRS web server. Microsoft does not have a Blazor component that is equivalent to the WinForms report viewer control. However, WinForms apps can show Blazor content via the BlazorWebView control. That provides a nice solution for brownfield applications that want to move to the Blazor UI model without having to convert everything. You could keep your SSRS reports using the WinForms report viewer control for now.

If you intend to move away from .NET Framework and move to .NET 6 or later, you will need to find a replacement technology for the SSRS reports.

[ajohnstone-ks]

We are very slowing moving to WPF from WinForms, but using MVVM. All new screens are WPF and we convert older ones. I think WPF has a reportviewer control built in.

[Chicagoan2016]

@ajohnstone-ks What are you folks using for MVVM? In the past, we had looked at Prism.
Thanks

[ossendorf-at-hoelscher]

We are using the MVVM Community Toolkit for WPF

• https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/

[ajohnstone-ks]

@Chicagoan2016 Same as @ossendorf-at-hoelscher, we are also using the community toolkit. For our actual VMs we just have a custom base VM which handle a few things that most VMs need, we haven't found a need to use someone else's base VM.

[swegele]

+1 for Blazor (server side interactive for LOB apps) - You get 'stateful app dev on the web'. Very productive. Obviously, there are many questions, but two most important to know if Blazor (as a web-ized desktop app) could work for you would be:

• do your clients have decent relatively low latency connections
• do you have extremely high concurrent user counts

If it works for you, I agree with Rocky...Blazor interactive server has taken everything we've thrown at it and it just keeps delivering. Very complex UIs, barcode stuff, multi-tab collaboration for user, dynamic user interfaces created by users, integrating 3rd party HTML5 and js apps. We translated a ~400 screen WebForms app and man what a dream compared to WebForms (rest in peace).

That said we have also made 3 different .net 6 side apps using Windows Forms using dependency injection as Rocky says. They work great. Personally I've never used WPF (TBH avoiding having to learn XAML).

[swegele]

Our app still uses Crystal Reports for our reporting. We offloaded that to a hybrid web api / web app since it requires .Net Framework legacy. But our Blazor app talks to the web api to prepare everything on the report side...and then opens a popup window which navigates the user to the crystal report viewer. Maybe that helps you see one possible way to offload that piece. HTH

[Chicagoan2016]

Great responses 👍👍
This one particular app we are considering is an extremely 'data entry' intensive application, that was the reason we had picked WinForms over ASP.NET back in the day.
Thoughts on Blazor with MAUI for 'data entry' types of apps?

Kind Regards

[swegele]

...extremely 'data entry' intensive application

That word "extremely" gives me pause.

If a user types VERY fast, and they are on a connection with some latency, it is possible they might bump up against a perceived lag in Blazor Server Interactive. Every keypress needs to be sent to the server over a web sockets connection. Tool vendors like Telerik expose a DebounceDelay property that can make a difference in user experience. I'm on Starlink internet and I type about ~50 wpm and I have not yet bumped against the lag but our customers enter data kind of "pulsed" with thinking giving time delays between typing.

I guess what I am saying is if your use of the word "extremely" is not exaggerated, then you might be right to get the UI (and thus the input speed) as close to the user as possible which then leads you toward:

• Winforms
• WPF
• Blazor WASM 

[rockfordlhotka]

This may be mitigated by the Blazor 8 automatic rendering mode feature, where the user ultimately ends up in a wasm page - only bridging through the server-interactive mode while the wasm code is downloaded in the background.

No messaging lag with a wasm page, because it is running on the client just like a winforms/wpf client app.

[swegele]

I've extensively "kicked the tires" with the auto modes over the last few weeks. I think it is fairly well established that .Net 9 will bring the finish and polish to these cool "at first glance" features. I don't have all the links but MS has heard clearly and repeatedly that this is needed. Dan Roth said that .NET 9 is focusing on "quality" for all the cool new turbulent stuff added in .NET 8. I saw one particularly aggravated post that said ".NET 8 is not ready until .NET 9?" :-) I found myself silently nodding my head. You will notice they took MS Identity options out of the Visual Studio 2022 Blazor Templates? Why you ask. Because the new .NET 8 stuff blows it all to heck. And so they just pulled them silently. Took me days to find Dan in a community standup saying why they did that and that they are working furiously to get it back in.

I've found one thing for sure that helps till .NET 9:

• Because of the flash issue - it's best to turn off PreRendering with interactive modes. You will know it when you see it...and I'm not so confident that a pre-render state preservation is a good solution.

Misc issues/thoughts:

• I did a bunch of tests trying to track how "Auto" mode works and I honestly found it VERY confusing especially when it comes to embedding components into pages. So I turned off Auto and things got much simpler.
• The laggy load of WASM pages is barely noticeable when in RELEASE mode (~ 1 second which is not bad). Whereas in DEBUG it takes like 7 to 10 seconds or more. So now I'm much less concerned about WASM in production and therefore less needy for AUTO and the complexity it brings (e.g. trying to do two service implementations in Client and Server project so it can run in both modes).
• Blazor Fluent library needs interactivity for it's services (like DialogService) which are declared on MainLayout.razor, so you either have to have all your pages globally defined, or you have to put the mode on the DialogService itself. But when you do that then things blow up when switching in AUTO. I was not able to figure that out.
• This example using YARP for reverse proxying AUTH requests from WASM to the Host and then on to your APIs is brilliant. It gets you going while we wait for .NET 9.

[swegele]

BTW - following that example I referenced just above...
I successfully and easily used YARP for SignalR traffic web socket...initiated in the Blazor WASM page directed to it's host which proxies it to a secured SignalR hub in separate WebAPI. So the WASM page has secured real time connection without revealing anything in client side code. All of it using MS Entra and Aspire. Very cool. Fun times.

[rockfordlhotka]

Similarly, I've spent the past few months diving into the Blazor 8 render mode stuff to get it working well with CSLA (or visa versa).

.NET 9 will have some fit-and-finish enhancements, but they aren't going to deal with some core issues I've had to solve with CSLA - mostly around state management and identify flow from server to client.

They are going to build in render mode detection. In the meantime this works:
https://blog.lhotka.net/2024/03/30/Blazor-8-Render-Mode-Detection

I've heard a lot of people saying they've avoided the auto capability because it is confusing, and I fully understand. I've been focused on figuring out how to make it work, because it is just too good (imo) to ignore.

Once state/identity flow and render mode detection are available, it becomes much easier to build a compelling app. What I've settled on, in collaboration with some folks on the Blazor team, seems pretty good to me.

1. Use server-static (streaming or not) for view-only stuff like reports, lists, etc.
2. Use InteractiveAuto for interactive pages
   a. Use render mode detection to not load data during server pre-render, but instead render placeholders or user indicators of what's coming
   b. Make sure to only enable interactive elements on the page (like buttons) when the page is in interactive mode - either don't display or disable interactive elements when the page is server-static rendered
   c. Call the data portal to load data when in an interactive render mode - server or wasm
   d. Host the data portal endpoint on the web server for simplicity - or elsewhere for scale
3. Use the CSLA 8 state management features - if not for LocalContext/ClientContext, at least to flow the ClaimsPrincipal from the server to the wasm pages automatically
4. Use server-static pages to implement any login/logout pages, because HttpContext is available in those pages

The result is (like ProjectTracker) the ability for a user to almost immediately see content and rapidly get an interactive experience via server-interactive, and ultimately shift the processing workload to the client device as the user interacts with the app.

The PageLifeCycle and RenderModes samples I maintain are a good way to understand the basic flow of pages/components and render modes.

[Chicagoan2016]

We have found Csla support for Winforms a breeze, e.g. Errorprovider controls with Csla-based objects, Binding support (and BindingSourceRefresh), and ReadWriterAuthorizer controls.
We need to look into Blazor with MAUI (as Rocky recommended). We are a small team and I am sure we are missing out on Blazor.
I almost forgot this project is 'old'. Initially, our UI was ASP.NET web forms (I am not kidding). Users hated it so we moved the Data entry UI to Winforms. We still have a little bit ASP.NET.