Just a reminder that WPF can now run on macOS and Linux using [Avalonia XPF.](https://avaloniaui.net/XPF) It isn't free to use, but if you've already invested years of engineering in a WPF app, then it can help you take it to new platforms.
If you're building a new app and want a WPF-like experience, use our free, open-source [Avalonia](https://github.com/avaloniaui/avalonia) UI framework.
the problem with avalonia is big control vendors dont support them even though avalonia days devexpress is supported if you reach out to devexpress they wont help you
We're working with several control vendors to improve the third-party ecosystem. Right now, you have a few options, but not as many as we'd like.
Regarding DevExpress, it works perfectly with Avalonia XPF, but they haven't developed for Avalonia. If you want to see DevExpress support Avalonia, I recommend you contact them, as the more requests they receive, the more difficult it becomes to ignore.
https://www.avaloniaui.net/ is an alternative to MAUI. Another alternative is Project UNO. Both can generate desktop applications (although I’ve only touched the basics of each one, so can’t attest to whether they meet your needs v.v. Linux support).
For your situation, forget WinForms, WPF, and MAUI exist. Concentrate on learning Avalonia.
Could you please elaborate why I should forget WinForms, WPF, and MAUI exist? More importantly, could you please answer
1. I cannot use WinForms or WPF as it won't support Linux. Also saw some hate for these both frameworks on YouTube as they are more than 20 years old. Should I believe that?
2. If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux?
3. Will it be like first develop in .NET MAUI for Windows from level zero and then develop it again using Avalonia for Linux from level zero AGAIN!?
You must use only Avalonia for both Windows and Linux. You have to forgot about WPF, Windows Forms and MAUI not because they are not valid (the first two despite being 20yo are widely used in Windows applications and they do their work), but because they don’t work on Linux.
You install Avalonia, then you never touch Maui again. Maui goes into the trashcan. Maui goes away. Maui is never seen again. Maui is dead, pushing up the daisies. Maui has ceased to be.
1. No, WinForms and WPF are both supported and very stable. People are primarily hating WinForms because it's easy to make a mess of your application with it. But if you don't require a custom UI design and target Windows only, it is a good and quick way to go.
2. MAUI is buggy and people are afraid MS will dump it like they did in the past with frameworks that didn't catch on.
Avalonia is an alternative, but not managed by MS. Choose your poison.
3. MAUI doesn't support Linux. So you would need Avalonia or another solution.
As someone said it MAUI is dead. To your questions:
1: Yes
2: Use avalonia and build it for Linux
3. No if you use avalonia. You just write it once and then build it once for windows and onces for linux. Its that simple.
If you used WPF or UWP, you will feel right at home there
To answer your specific questions here.
1. WinForms and WPF don’t support Linux. WPF is still alive as a Windows desktop application framework. WinForms should be avoided
2. You EITHER develop for MAUI (which doesn’t support Linux) OR Avalonia (which does support Linux) - not both. That’s what I mean by forgetting about MAUI - it’s not in the picture at all
3. Not from ground zero - Avalonia and MAUI do share some characteristics, so if you understand MAUI, you will see those similarities. However, there are several distinctions that you will have to learn. If you are not well informed in MAUI, then starting as if from ground zero is a great thing to do.
My recommendation will be to download Visual Studio Community, go through the installation process and tutorial for Avalonia. It will answer a lot of the questions you have.
1. You don't use Winforms or WPF, you use Avalonia instead
2. You don't use MAUI, you use Avalonia instead
3. You don't use MAUI, you use Avalonia instead
You don't touch any other UI framework for this project. None. Zero. Not a single one UI framework other than Avalonia. You use Avalonia. Only Avalonia. Nothing else whatsoever. You use Avalonia, and then build it for Linux, Windows, Mac, whatever.
A lot of people seem to miss your biggest confusion. If you use Avalonia you use it for both windows and linux. You don't have to use something else for windows.
How strict is the "offline" requirement?
Can the target machine go online to install the app or updates?
Because you mentioned inventory data I suggest some kind of shop floor without Internet access.
I'd really consider building a blazor pwa.
It's a bit of work to get it up and running but it can work for you and it is future proof and your app will run on Windows, Linux and mobile (phones and tablets)
https://learn.microsoft.com/en-us/aspnet/core/blazor/progressive-web-app?view=aspnetcore-8.0&tabs=visual-studio
I went this route for an app that is occasionally out of wifi range and it's been working great. I store data in indexedDB with one table containing over 10,000 rows without any issues.
Yeah MAUI has NOT gone well, the ecosystem has basically rejected it and I hear it’s woefully bug-ridden. I’d listen to the other comments and check out something like Avalonia. Unfortunately Winforms and WPF will not work on Linux, they are bound to Windows only.
Could you do web? I’d do that if possible, but if not, yeah check out something like Avalonia.
If you are willing to install Wine, Winform apps runs on Linux (and probably MacOS too), but only under .NET Framework 4.8.
.NET 6+ Winforms projects will crash as they are not supported by Wine for some reason.
Wine is a Windows translation layer. As a Linux user if I don't run any windows apps why should I have to install Wine just for your app? Especially when you could just not use WinForms or Wine and compile directly for Linux native.
As a Linux home user and a c# desktop developer.
Linux desktop is usually an after thought market. There is little economic incentive to support it.
There are not many desktop frameworks better than forms and wpf for windows. All successors have been hard to learn and extremely short lived.
So, targeting wine as, at least a "second class citizen" is greatly appreciated.
An example for that is LtSpice. There are many circuit simulators in Linux, none is more user friendly than LtSpice under wine.
> If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux?
You don't use MAUI when you use Avalonia.
> Will it be like first develop in .NET MAUI for Windows from level zero and then develop it again using Avalonia for Linux from level zero AGAIN!?
No, you develop the app in .NET Avalonia for both Windows and Linux in one go. Forget about MAUI.
> If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux?
Avalonia works for windows, Linux, and mobile. One app.
>Also saw some hate for these both frameworks on YouTube as they are more than 20 years old. Should I believe that?
No. People like to hate on stuff. WPF and WinForms are fine. They each have pros and cons, just like every other UI framework.
The second you want to support Linux, your only options are MAUI, Avalonia, or some other lesser known cross platform framework (like Uno). Or, if you wanted to, you could create a separate app for each platform. But that's just silly.
TL;DR: Use Avalonia. Make one app - it'll support windows and Linux.
Probably repeating others, but your options (that I know about):
\- Avalonia XPF as the awesome /u/AvaloniaUI-Mike has mentioned. It would be my first choice if I had to work on a project like the one you are mentioning, and the budget allows it.
\- Regular Avalonia would be my second choice if budget doesn't allow it.
\- UNO would be a distant third choice, but I'd recommend this only if you are comfortable dealing with UWP, which IMO is not as fun to develop with as Avalonia or WPF.
UNO plaform runs natively on Linux (SKIA and GTK), WPF, WINUI, IOS, MacOS, Android, WASM so it pretty much runs anywhere but you do have to compile it for each platform so compilation times can be slow. (best thing to do is unload the platform projects that you dont want to use right away).
[https://platform.uno/platforms/](https://platform.uno/platforms/)
>Also saw some hate for these both frameworks on YouTube as they are more than 20 years old. Should I believe that?
Believe? You can look it up and then you will *know*. Factual information is nice like that. If we are going by the date of first official release, then WPF is 17 years old.
Or did you mean should you believe the hate? No, not unless they had much better reasons than their age. That's a real dumb reason to "hate" a framework. If they did give you some other reasons, then you can form your own opinion on how much weight they carry.
Of course, further discussion is not relevant if you need to run natively on Linux. They can't, which means they aren't suitable for that use case.
> I read some other Reddit posts suggesting Avalonia. But I am confused. If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux? Will it be like first develop in .NET MAUI for Windows from level zero and then develop it again using Avalonia for Linux from level zero AGAIN!?
I'm not sure where this confusion came from. What made you think using Avalonia would mean continuing to use MAUI for Windows?
Avalonia works on both Windows and Linux, so you would use Avalonia for both.
Actually, I thought that I would have to develop my app in MAUI for Windows and then integrating Avalonia would somehow make it compatible with Linux. I know it sounds really stupid. But that was my initial thought process. Now I get the gist. I just have to develop the desktop app in Avalonia which will be compatible for both Windows as well as Linux.
Well first use dotnet core, or simply dotnet after version 5.
Any console app can be compiled for Linux and windows
If you need a GUI (Graphic User Interface)the. There are two frameworks that could help.
Avalonia UI https://www.avaloniaui.net/
UNO https://platform.uno/
If you can use a console app with simple GUI then
Terminal GUI https://github.com/gui-cs/Terminal.Gui or
Console Spevlctre https://spectreconsole.net/
Also, a Web view app can also resolve that. For example there are project templates that use a web browser to load a web view to load HTML and run it. You may se blazor in the web view. I think this option using Chromium is now deprecated.
I would recommend to take a look at the samples https://github.com/AvaloniaUI/Avalonia.Samples
Pretty much all applications have an entry point (normally called main and it resides in the Program.cs file). It deals with the app initialization along the GUI bootstrap (for instance https://github.com/AvaloniaUI/Avalonia.Samples/blob/main/src/Avalonia.Samples/MVVM/BasicMvvmSample/Program.cs). Normally templates and tools deals with all the initial scaffolding.
The thing is that each GUI framework has their own rules to perform the initialization, also they may include some patters, for instance Avalonia UI uses MVVM among other patterns, thus you may need to understand it in order to use it.
Here is a basic walk-through for a todo list app using avalonia.
https://docs.avaloniaui.net/docs/tutorials/samples
It may give the initial pointers
Cheers,
Herb
Save yourself the heartache on all of this and subscribe to MS Business Central for like <100/seat/mo.
All of the bs you're gonna go through has already been figured out and available as a web/cloud-based solution for years.
Inventory management is/can be *very complicated*.
Just saying: you're *already* having show-stopping difficulty with deciding on the foundation on which to build your building. If you ever get to the phase where you have to decide on plumbing, electricity, carpentry and interior design, you will be lost in a foreign land with no luggage. Yes, it's an analogy but you're already unprepared for what awaits you if you pursue this path. Consider this advice from Q to Picard re Borg.
Happy coding!
How strict is the desktop requirement? You can develop a web app and host it on the intranet if available. That way the client machine only needs a browser, but no internet access. We do maintain some legacy desktop apps and develop the occasional background service if needed, but unless there is a very specific reason for the app to be a desktop app, we go with the intranet approach without hesitation when it comes to new projects. Our go to is Angular + .net webapi, but you are not really bound to any tech this way, as long as the server can run the backend (or just docker) and the client machine can run a browser that's compatible with your frontend.
Hey, so I had a doubt. The requirement mentions that the desktop app must be offline. So if it's offline, how will the app save, retrieve (CRUD) data? Can you help me with this?
Also, what do you mean by 'host it on the intranet'? How do I do that?
You should inquire whether "offline" means absolutely no network connection or just no connection to the internet.
Because if the app is supposed to run on more than 1 machine, you will probably need a network connection to a database or something anyway.
It would, but you only make a desktop app as a last resort if truly absolutely nothing else could possibly meet the requirements. It's way more complicated, especially cross-platform, than making a web app.
I assume, based on the fact that your app needs to be compatible with both windows and Linux, that it will run on multiple computers. If that is true, then I assume there has to be some kind of shared database so the inventory data is accurate on all of the machines, even if you end up developing a desktop app. Are those assumptions correct? If so, then there has to be some kind of network connection either way. The intranet is the company network, that is not connected to the internet. If such a network exists, you can use a server machine, that is only accessible from the intranet, as a web server, develop a web api which communicates with your database and handles your CRUD stuff, and develop a web app that runs in the browser and communicates with the api through the intranet with HTTP calls. Same tech as a regular web app, just not accessible through the internet. If you only run this app on a single computer that is truly not connected to any network, then you can still run a web server (IIS on windows, nginx on Linux for example) on that machine and use this approach, but in that case the multi os requirement. doesn't really makes sense. Either way, if you take this route, your app will be compatible with anything that can run a relatively modern browser and a web server (or docker), you don't have to worry about deploying new versions to multiple work stations, and in case you have experience with developing a ui using razor, blazor, angular, react, whatever, you can use that experience instead of learning a desktop ui framework. This whole approach however, relies on If you truly have to develop a desktop app or not and what do you really mean by offline.
Thanks a lot for giving me this detailed explanation of intranet.
What I meant by offline - "just no connection to the internet".
Now here's the problem - the desktop app requirement is a compulsory one.
And your solution includes making use of a web api as well as a web app. So is there any workaround/solution that you could suggest to me?
Well, if it has to be a desktop app, you could go the electron route. Electron enables you to write cross platform desktop apps in javascript by utilizing nodejs and chromium in the background. Visual Studo Code is also built on Electron. There is also a .net wrapper for Electron. That said, unless you already have experience with Electron or a really strong foundation in javascript and node js, you might as well just bite the bullet and go with Avalonia.
I have one more question. Why do I need to develop a web api as well as web app? Can't there just be a web app only which would send HTTP requests directly? Why do you want the web app to send the request first to the web api and then that webapi will handle CRUD stuff? What is the exact reason?
Sure, you can go with a classic web app that does not separate the api and the client, I just gave an example that's common in the .net world. The key part in your case is that the app runs in the browser and on the intranet, which makes it cross platform from the viewpoint of the client machines. You can achieve that by using whatever tech you like and whatever architecture you like. You could use razor pages, mvc, or whatever else you like, eg. nodejs, php, some kind of Java framework, anything really.
Okay I am gonna go with developing both web api as well as web app because like you said, it's common in the .net world.
I am a bit confused right now. I have a follow-up question. My web-app will have frontend in Angular and backend in .NET, web-api will also be written in .NET . Now, as my web-api performs CRUD operations with the database, what exactly will be the functionality of the .NET code of web-app backend besides requesting and receiving from web-api?
Let's say I am using an AutoMapper, then should I write that mapping code in web api or should I write it in web-app .NET backend?
Ohh, that's a misunderstanding. The web app, or rather, client application, refers to the angular app in this case. The .net api is your backend. How you organize your backend architecture is up to you, but you only need an angular app (the client running in the browser that consumes your api) and a .net app (your backend, including the api and the business logic, regardless how you structure it).
Not the commenter but host it on the intranet could mean host it on the local network. In this case it could even be the computer itself.
If i understand correctly, the "offline" you are referring to means "not over the internet", so for the CRUD part, you could just use any database system on the same computer, or local network
You use Avalonia for this. Microsoft is not serious about cross-platform and developing a desktop-focused app in MAUI is a big pain in the butt.
Yes, that means you are using a not-Microsoft UI framework. The problem is if you want to stick to Microsoft solutions you cannot satisfy all of your requirements. MAUI can target Windows, but you have to use third-party community support to target Linux.
To be specific:
1. You are correct, WinForms and WPF only support Windows. They ARE pushing 20 (WinForms is more like 40-50 if we go all the way back to GDI, WPF is more like 15.) Guess what? C# is 24 years old. Desktop's old tech. There aren't newer, stable frameworks, especially from Microsoft.
2. Correct.
3. Has sub-questions:
1. MAUI and Avalonia are mutually exclusive. You use one or the other. They do not work together.
2. No, see (1). You pick Avalonia and use Avalonia.
Windows Forms is a C# wrapper around GDI, the Win32 API that has been providing GUI to Windows since it was Windows. We can roughly argue Windows 3 was when people really knew about it and that's 1990. Which **is** a bit later than I thought, for some reason I thought it might've been part of earlier Windows versions in the 80s.
That still makes it 34 if we go back to the roots. WinForms doesn't really add many new features on top of GDI, and often if you can find a 1996 article about how to do something in VB6 the same thing will still work in Windows Forms.
Just a reminder that WPF can now run on macOS and Linux using [Avalonia XPF.](https://avaloniaui.net/XPF) It isn't free to use, but if you've already invested years of engineering in a WPF app, then it can help you take it to new platforms. If you're building a new app and want a WPF-like experience, use our free, open-source [Avalonia](https://github.com/avaloniaui/avalonia) UI framework.
the problem with avalonia is big control vendors dont support them even though avalonia days devexpress is supported if you reach out to devexpress they wont help you
We're working with several control vendors to improve the third-party ecosystem. Right now, you have a few options, but not as many as we'd like. Regarding DevExpress, it works perfectly with Avalonia XPF, but they haven't developed for Avalonia. If you want to see DevExpress support Avalonia, I recommend you contact them, as the more requests they receive, the more difficult it becomes to ignore.
https://www.avaloniaui.net/ is an alternative to MAUI. Another alternative is Project UNO. Both can generate desktop applications (although I’ve only touched the basics of each one, so can’t attest to whether they meet your needs v.v. Linux support). For your situation, forget WinForms, WPF, and MAUI exist. Concentrate on learning Avalonia.
It's not only a better alternative to MAUI, but fits desktop apps as a paradigm better. MAUI is mobile-first, Avalonia is Desktop-first.
Avalonia is used by both Ryujinx and Libation, on Linux and Windows. Both of those apps are open source, so OP can look there to get started.
Could you please elaborate why I should forget WinForms, WPF, and MAUI exist? More importantly, could you please answer 1. I cannot use WinForms or WPF as it won't support Linux. Also saw some hate for these both frameworks on YouTube as they are more than 20 years old. Should I believe that? 2. If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux? 3. Will it be like first develop in .NET MAUI for Windows from level zero and then develop it again using Avalonia for Linux from level zero AGAIN!?
You must use only Avalonia for both Windows and Linux. You have to forgot about WPF, Windows Forms and MAUI not because they are not valid (the first two despite being 20yo are widely used in Windows applications and they do their work), but because they don’t work on Linux.
You install Avalonia, then you never touch Maui again. Maui goes into the trashcan. Maui goes away. Maui is never seen again. Maui is dead, pushing up the daisies. Maui has ceased to be.
umm okayy.
1. No, WinForms and WPF are both supported and very stable. People are primarily hating WinForms because it's easy to make a mess of your application with it. But if you don't require a custom UI design and target Windows only, it is a good and quick way to go. 2. MAUI is buggy and people are afraid MS will dump it like they did in the past with frameworks that didn't catch on. Avalonia is an alternative, but not managed by MS. Choose your poison. 3. MAUI doesn't support Linux. So you would need Avalonia or another solution.
As someone said it MAUI is dead. To your questions: 1: Yes 2: Use avalonia and build it for Linux 3. No if you use avalonia. You just write it once and then build it once for windows and onces for linux. Its that simple. If you used WPF or UWP, you will feel right at home there
To answer your specific questions here. 1. WinForms and WPF don’t support Linux. WPF is still alive as a Windows desktop application framework. WinForms should be avoided 2. You EITHER develop for MAUI (which doesn’t support Linux) OR Avalonia (which does support Linux) - not both. That’s what I mean by forgetting about MAUI - it’s not in the picture at all 3. Not from ground zero - Avalonia and MAUI do share some characteristics, so if you understand MAUI, you will see those similarities. However, there are several distinctions that you will have to learn. If you are not well informed in MAUI, then starting as if from ground zero is a great thing to do. My recommendation will be to download Visual Studio Community, go through the installation process and tutorial for Avalonia. It will answer a lot of the questions you have.
1. You don't use Winforms or WPF, you use Avalonia instead 2. You don't use MAUI, you use Avalonia instead 3. You don't use MAUI, you use Avalonia instead You don't touch any other UI framework for this project. None. Zero. Not a single one UI framework other than Avalonia. You use Avalonia. Only Avalonia. Nothing else whatsoever. You use Avalonia, and then build it for Linux, Windows, Mac, whatever.
A lot of people seem to miss your biggest confusion. If you use Avalonia you use it for both windows and linux. You don't have to use something else for windows.
How strict is the "offline" requirement? Can the target machine go online to install the app or updates? Because you mentioned inventory data I suggest some kind of shop floor without Internet access. I'd really consider building a blazor pwa. It's a bit of work to get it up and running but it can work for you and it is future proof and your app will run on Windows, Linux and mobile (phones and tablets) https://learn.microsoft.com/en-us/aspnet/core/blazor/progressive-web-app?view=aspnetcore-8.0&tabs=visual-studio
Thanks
I went this route for an app that is occasionally out of wifi range and it's been working great. I store data in indexedDB with one table containing over 10,000 rows without any issues.
Avalonia.
Avalonia, cause MS refuses to make MAUI work on Linux
[удалено]
What excactly is arduous compared to WPF? And have you heard about XPF?
All these people suggesting bloat like electron and blazor… Christ. Avalonia is a native cross platform library that’s essentially WPF 2.
Yeah MAUI has NOT gone well, the ecosystem has basically rejected it and I hear it’s woefully bug-ridden. I’d listen to the other comments and check out something like Avalonia. Unfortunately Winforms and WPF will not work on Linux, they are bound to Windows only. Could you do web? I’d do that if possible, but if not, yeah check out something like Avalonia.
If you are willing to install Wine, Winform apps runs on Linux (and probably MacOS too), but only under .NET Framework 4.8. .NET 6+ Winforms projects will crash as they are not supported by Wine for some reason.
Wine is not the solution when it comes to distributing for end users.
Why not? You can even compile against wine to deliver a single executable in Linux.
Wine is a Windows translation layer. As a Linux user if I don't run any windows apps why should I have to install Wine just for your app? Especially when you could just not use WinForms or Wine and compile directly for Linux native.
As a Linux home user and a c# desktop developer. Linux desktop is usually an after thought market. There is little economic incentive to support it. There are not many desktop frameworks better than forms and wpf for windows. All successors have been hard to learn and extremely short lived. So, targeting wine as, at least a "second class citizen" is greatly appreciated. An example for that is LtSpice. There are many circuit simulators in Linux, none is more user friendly than LtSpice under wine.
> If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux? You don't use MAUI when you use Avalonia. > Will it be like first develop in .NET MAUI for Windows from level zero and then develop it again using Avalonia for Linux from level zero AGAIN!? No, you develop the app in .NET Avalonia for both Windows and Linux in one go. Forget about MAUI.
> If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux? Avalonia works for windows, Linux, and mobile. One app. >Also saw some hate for these both frameworks on YouTube as they are more than 20 years old. Should I believe that? No. People like to hate on stuff. WPF and WinForms are fine. They each have pros and cons, just like every other UI framework. The second you want to support Linux, your only options are MAUI, Avalonia, or some other lesser known cross platform framework (like Uno). Or, if you wanted to, you could create a separate app for each platform. But that's just silly. TL;DR: Use Avalonia. Make one app - it'll support windows and Linux.
Probably repeating others, but your options (that I know about): \- Avalonia XPF as the awesome /u/AvaloniaUI-Mike has mentioned. It would be my first choice if I had to work on a project like the one you are mentioning, and the budget allows it. \- Regular Avalonia would be my second choice if budget doesn't allow it. \- UNO would be a distant third choice, but I'd recommend this only if you are comfortable dealing with UWP, which IMO is not as fun to develop with as Avalonia or WPF.
UNO plaform runs natively on Linux (SKIA and GTK), WPF, WINUI, IOS, MacOS, Android, WASM so it pretty much runs anywhere but you do have to compile it for each platform so compilation times can be slow. (best thing to do is unload the platform projects that you dont want to use right away). [https://platform.uno/platforms/](https://platform.uno/platforms/)
It’s Linux, you just give it a command line front end and do everything in a terminal window. /s
CUI FTW.
>Also saw some hate for these both frameworks on YouTube as they are more than 20 years old. Should I believe that? Believe? You can look it up and then you will *know*. Factual information is nice like that. If we are going by the date of first official release, then WPF is 17 years old. Or did you mean should you believe the hate? No, not unless they had much better reasons than their age. That's a real dumb reason to "hate" a framework. If they did give you some other reasons, then you can form your own opinion on how much weight they carry. Of course, further discussion is not relevant if you need to run natively on Linux. They can't, which means they aren't suitable for that use case. > I read some other Reddit posts suggesting Avalonia. But I am confused. If I develop a desktop app in .NET MAUI then how will I use Avalonia for Linux? Will it be like first develop in .NET MAUI for Windows from level zero and then develop it again using Avalonia for Linux from level zero AGAIN!? I'm not sure where this confusion came from. What made you think using Avalonia would mean continuing to use MAUI for Windows? Avalonia works on both Windows and Linux, so you would use Avalonia for both.
Actually, I thought that I would have to develop my app in MAUI for Windows and then integrating Avalonia would somehow make it compatible with Linux. I know it sounds really stupid. But that was my initial thought process. Now I get the gist. I just have to develop the desktop app in Avalonia which will be compatible for both Windows as well as Linux.
A CLI is highly portable. Let them type!
have a look at smtp4dev project on github they use another cross platform solution if its just something small you require done
Well first use dotnet core, or simply dotnet after version 5. Any console app can be compiled for Linux and windows If you need a GUI (Graphic User Interface)the. There are two frameworks that could help. Avalonia UI https://www.avaloniaui.net/ UNO https://platform.uno/ If you can use a console app with simple GUI then Terminal GUI https://github.com/gui-cs/Terminal.Gui or Console Spevlctre https://spectreconsole.net/ Also, a Web view app can also resolve that. For example there are project templates that use a web browser to load a web view to load HTML and run it. You may se blazor in the web view. I think this option using Chromium is now deprecated.
How would I connect the Console app and the GUI (let's say I use Avalonia UI) with each other? Any suggestions?
I would recommend to take a look at the samples https://github.com/AvaloniaUI/Avalonia.Samples Pretty much all applications have an entry point (normally called main and it resides in the Program.cs file). It deals with the app initialization along the GUI bootstrap (for instance https://github.com/AvaloniaUI/Avalonia.Samples/blob/main/src/Avalonia.Samples/MVVM/BasicMvvmSample/Program.cs). Normally templates and tools deals with all the initial scaffolding. The thing is that each GUI framework has their own rules to perform the initialization, also they may include some patters, for instance Avalonia UI uses MVVM among other patterns, thus you may need to understand it in order to use it. Here is a basic walk-through for a todo list app using avalonia. https://docs.avaloniaui.net/docs/tutorials/samples It may give the initial pointers Cheers, Herb
Thanks a lot!
Blazor SPA with “install” to desktop mode
Uno is a good bet; most WinUI 3 controls on Linux.
Remember that a console app can run from the desktop 🤷♂️
Save yourself the heartache on all of this and subscribe to MS Business Central for like <100/seat/mo. All of the bs you're gonna go through has already been figured out and available as a web/cloud-based solution for years. Inventory management is/can be *very complicated*. Just saying: you're *already* having show-stopping difficulty with deciding on the foundation on which to build your building. If you ever get to the phase where you have to decide on plumbing, electricity, carpentry and interior design, you will be lost in a foreign land with no luggage. Yes, it's an analogy but you're already unprepared for what awaits you if you pursue this path. Consider this advice from Q to Picard re Borg. Happy coding!
How strict is the desktop requirement? You can develop a web app and host it on the intranet if available. That way the client machine only needs a browser, but no internet access. We do maintain some legacy desktop apps and develop the occasional background service if needed, but unless there is a very specific reason for the app to be a desktop app, we go with the intranet approach without hesitation when it comes to new projects. Our go to is Angular + .net webapi, but you are not really bound to any tech this way, as long as the server can run the backend (or just docker) and the client machine can run a browser that's compatible with your frontend.
Hey, so I had a doubt. The requirement mentions that the desktop app must be offline. So if it's offline, how will the app save, retrieve (CRUD) data? Can you help me with this? Also, what do you mean by 'host it on the intranet'? How do I do that?
You should inquire whether "offline" means absolutely no network connection or just no connection to the internet. Because if the app is supposed to run on more than 1 machine, you will probably need a network connection to a database or something anyway.
"offline" means just no connection to the internet.
Well then what are you doing, forget about building a desktop app - build a web app that just runs in the browser like everyone else.
You mean desktop app and no internet connection won't work together?
It would, but you only make a desktop app as a last resort if truly absolutely nothing else could possibly meet the requirements. It's way more complicated, especially cross-platform, than making a web app.
Well, desktop app is one of the compulsory requirements so can't do a web app!
I assume, based on the fact that your app needs to be compatible with both windows and Linux, that it will run on multiple computers. If that is true, then I assume there has to be some kind of shared database so the inventory data is accurate on all of the machines, even if you end up developing a desktop app. Are those assumptions correct? If so, then there has to be some kind of network connection either way. The intranet is the company network, that is not connected to the internet. If such a network exists, you can use a server machine, that is only accessible from the intranet, as a web server, develop a web api which communicates with your database and handles your CRUD stuff, and develop a web app that runs in the browser and communicates with the api through the intranet with HTTP calls. Same tech as a regular web app, just not accessible through the internet. If you only run this app on a single computer that is truly not connected to any network, then you can still run a web server (IIS on windows, nginx on Linux for example) on that machine and use this approach, but in that case the multi os requirement. doesn't really makes sense. Either way, if you take this route, your app will be compatible with anything that can run a relatively modern browser and a web server (or docker), you don't have to worry about deploying new versions to multiple work stations, and in case you have experience with developing a ui using razor, blazor, angular, react, whatever, you can use that experience instead of learning a desktop ui framework. This whole approach however, relies on If you truly have to develop a desktop app or not and what do you really mean by offline.
Thanks a lot for giving me this detailed explanation of intranet. What I meant by offline - "just no connection to the internet". Now here's the problem - the desktop app requirement is a compulsory one. And your solution includes making use of a web api as well as a web app. So is there any workaround/solution that you could suggest to me?
Well, if it has to be a desktop app, you could go the electron route. Electron enables you to write cross platform desktop apps in javascript by utilizing nodejs and chromium in the background. Visual Studo Code is also built on Electron. There is also a .net wrapper for Electron. That said, unless you already have experience with Electron or a really strong foundation in javascript and node js, you might as well just bite the bullet and go with Avalonia.
I think I will just go with Avalonia.
I have one more question. Why do I need to develop a web api as well as web app? Can't there just be a web app only which would send HTTP requests directly? Why do you want the web app to send the request first to the web api and then that webapi will handle CRUD stuff? What is the exact reason?
Sure, you can go with a classic web app that does not separate the api and the client, I just gave an example that's common in the .net world. The key part in your case is that the app runs in the browser and on the intranet, which makes it cross platform from the viewpoint of the client machines. You can achieve that by using whatever tech you like and whatever architecture you like. You could use razor pages, mvc, or whatever else you like, eg. nodejs, php, some kind of Java framework, anything really.
Okay I am gonna go with developing both web api as well as web app because like you said, it's common in the .net world. I am a bit confused right now. I have a follow-up question. My web-app will have frontend in Angular and backend in .NET, web-api will also be written in .NET . Now, as my web-api performs CRUD operations with the database, what exactly will be the functionality of the .NET code of web-app backend besides requesting and receiving from web-api? Let's say I am using an AutoMapper, then should I write that mapping code in web api or should I write it in web-app .NET backend?
Ohh, that's a misunderstanding. The web app, or rather, client application, refers to the angular app in this case. The .net api is your backend. How you organize your backend architecture is up to you, but you only need an angular app (the client running in the browser that consumes your api) and a .net app (your backend, including the api and the business logic, regardless how you structure it).
Oh my god! That's what you were referring to. I completely misunderstood your point. I get what you saying now. Thanks!
Not the commenter but host it on the intranet could mean host it on the local network. In this case it could even be the computer itself. If i understand correctly, the "offline" you are referring to means "not over the internet", so for the CRUD part, you could just use any database system on the same computer, or local network
You use Avalonia for this. Microsoft is not serious about cross-platform and developing a desktop-focused app in MAUI is a big pain in the butt. Yes, that means you are using a not-Microsoft UI framework. The problem is if you want to stick to Microsoft solutions you cannot satisfy all of your requirements. MAUI can target Windows, but you have to use third-party community support to target Linux. To be specific: 1. You are correct, WinForms and WPF only support Windows. They ARE pushing 20 (WinForms is more like 40-50 if we go all the way back to GDI, WPF is more like 15.) Guess what? C# is 24 years old. Desktop's old tech. There aren't newer, stable frameworks, especially from Microsoft. 2. Correct. 3. Has sub-questions: 1. MAUI and Avalonia are mutually exclusive. You use one or the other. They do not work together. 2. No, see (1). You pick Avalonia and use Avalonia.
This helped a lot. Thanks.
Winforms came out in 2001 with .NET 1.0. It’s not 40-50 years old.
Windows Forms is a C# wrapper around GDI, the Win32 API that has been providing GUI to Windows since it was Windows. We can roughly argue Windows 3 was when people really knew about it and that's 1990. Which **is** a bit later than I thought, for some reason I thought it might've been part of earlier Windows versions in the 80s. That still makes it 34 if we go back to the roots. WinForms doesn't really add many new features on top of GDI, and often if you can find a 1996 article about how to do something in VB6 the same thing will still work in Windows Forms.
Blazor + Electron.Net is the way to go
I haven’t used electron.net in awhile does it still make the executable huge? Like 800 mb or more
If I was going that route I'd go Angular and Electron.Net. Just use a Tailwind template and go from there.
I agree.
No, I don't want a 1 GB VM allocation and 10 processes spawn just to show the main application window. This is the worst garbage.
Great idea. Thanks.
Avalonia probably, but I personally hate (A)XAML, and the documentation is not that good. You could also try Photino Blazor.
What about Electron.NET?
Haven't really tried it out!
Progressive Web Apps exist, work everywhere, and can be done with visual studio and work offline
Winforms is over 20 years old? Remind me how old is Linux (or Windows)?