Point 1 is largely true, Microsoft builds too many competing UI toolkits.
Point 3: You can slim down Visual Studio's install a lot if you're more selective during installation. For example if I only wanted to do .Net desktop application development it is closer to 4 GB and under 10 GB on disk.
Point 4: Is actually the end of the original synopsis on the topic and after it veers off. You successfully built the application.
Now it goes a little off the rails:
Point 5: "The app is extremely resource heavy and way too over-featured." Ok? You didn't say which toolkit, guide, or similar you used nor what you define as resource heavy or in what way it was "over-featured." This is too vague to discuss meaningfully (e.g. Win32 applications built in C++ definitely aren't resource heavy or over-featured for example, and since you didn't clarify even what tech stack was used let alone guide/template this isn't constructive at all).
Point 6: I've read this sentence several times but seemingly you opened an executable in a text editor and that somehow broke your build process? Or something? Was it write-locked by the editor?
Point 7-10: You had a working build pipeline, you broke the pipeline, then decided to start again from scratch in an editor that doesn't have native desktop development support on Windows (because the old editor was "bloated"). You found this process problematic.
So in answer to:
> Why is building Windows apps so complicated
You made it complicated by using unsupported workflows and introducing arbitrary limitations on what was a successful outcome. There's a lot you can legitimately criticize Windows and even its desktop application development workflow for, but this isn't that.
Speaking as somebody who spent years developing Windows desktop apps professionally, yes this pretty much. Visual Studio is admittedly a bit bloated and can be slow, but it's pretty much the only game in town when it comes to building Windows desktop apps. Jetbrains Rider might be okay, never tried it. Don't even bother trying to use any alternate text editors or you'll be in a world of pain.
People used to doing development for Unixy CLI apps or web stuff tend to try to use their familiar tools when trying to do Windows desktop app development, and run into a ton of problems. The solution is, don't do that. Use Visual Studio the way it was meant to be used.
Also, in the web world, it may be less of a pain to always use the newest hottest thing. Microsoft does have a tendency to produce half-baked new UI frameworks and over-hype them before abandoning them, so people used to the web world way of figuring out what to use tend to get sucked into them and then get frustrated. IMO, stick to C# WinForms to get going, and use it until you know you need something it doesn't do well.
>IMO, stick to C# WinForms to get going, and use it until you know you need something it doesn't do well.
Heh, as per the discussion above, this really should be prefixed with "unpopular opinion:", since you really don't see a lot of recommendations that people use WinForms for anything these days.
WinForms is actually super nice, and given how many toolkits MS released after that, latest one even without working GUI designer, I'd say WinForms is one of the best options available.
5. I wanted to build a Hello World App remember, to develop windows apps, they told me to download Visual Studio with the following features selected: workflows: Universal Windows Platform development, .NET Desktop Development, Desktop development with C++. Individual components: Windows 10 SDK (10.0.19041.0) and C++ (v142) Universal Windows Platform tools. I found all that unnecessary for Hello World but I was following a guide: https://docs.microsoft.com/en-us/windows/apps/windows-app-sd...
6-. Visual Studio was too heavy for my 7th gen Intel laptop so I switched to Sublime Text to work over there because I thought all build tools was installed. I tried to run "dotnet build" but it didn't work. "msbuild" worked but i don't know to run the built app.
Your experience is expected for the framework. That thing is brand new, has questionable architecture, and I'm not sure MS will be able to fix.
The old and stable stuff is WPF (GPU-based on top of Direct3D 9) and Windows Forms (a C# wrapper around Win32, easier to use when you don't have a professionally-made GUI design).
> Visual Studio was too heavy for my 7th gen Intel laptop
VS2017 runs great on my old laptop with Core-i3 CPU from 2016. It's not the CPU. Ensure you have enough RAM, the system drive is a fast SSD with enough free space, and it's not a software issue like malware or an equivalent.
> VS2017 runs great on my old laptop with Core-i3 CPU from 2016.
For the last 1 or probably 2 years now I've been using VS2019 quite successfully on a 10 year old laptop with an i7-3520M (+ 16gb RAM & SSD).
Yes, its way heavier and clunkier than something like Eclipse for example and I do whinge a lot about how it loves to chew a lot of CPU and get a bit laggy when I'm typing code (why does Roslyn need 50%++ while I'm typing a comment? Is it really that interesting?)
But it is still useable nonetheless. The main issue I have with it is that touchpad scrolling in the code window really sucks and VS is really buggy in general needing restarts several times a day or things start getting 'weird'.
Apparently, 80% of recent laptops are engineered for web browsing and very light office workloads, even regardless on their price. Despite the CPUs are generally good, they don’t usually install enough RAM in them. It started to change recently, half of the new ones have 16GB RAM which is good for development at the moment. But that wasn’t the case in 2016 when Intel released Kaby Lake CPUs the OP has.
> agreeing with OP that the situation is awful?
I looked at WinUI3 not long ago, and didn’t like it too much. I wouldn’t call the situation “awful”, but it’s not good either, neither for OP nor Microsoft.
The Windows GUI software I develop for living is often based on WPF. I think it’s superior despite much older: amount of bugs, quality of tools, binary size, etc. Fortunately for the OP, WPF is still supported in latest versions of .NET and Visual Studio, and is very likely to stay that way.
Neither WPF nor WinUI are using OS controls for most of their GUI. Their GUI is defined by styles and templates in various XAML files. You can make controls look however you like. Microsoft did a great job back then re-implementing UX of WinXP and Win7 on top of WPF, but unfortunately not the newer Windows versions.
Here’s a third-party project with styles and templates implementing GUI similar to Win10: https://github.com/Kinnara/ModernWpf Their approach seems correct, and the screenshots looking nice. I never needed that library BTW, my clients who need good GUI usually provide professionally-made design which is unrelated to Windows controls.
Also, here’s a relevant GitHub issue https://github.com/dotnet/wpf/issues/5793 which currently says “.NET 7.0 milestone”, however the 7.0 is scheduled for November 2022, i.e. in about 1 year, and they may or may not deliver by then.
VSCode has issues with MSBuild for all but the easiest (read: Recent .NET version, targeting the web) to build projects. It'll be difficult to get by without VS unless you're a wizard, in which case you're probably stockholm syndromed into VS anyway.
> Point 6: I've read this sentence several times but seemingly you opened an executable in a text editor and that somehow broke your build process? Or something? Was it write-locked by the editor?
I can't imagine how you got to that interpretation.
Obviously what OP meant was that they wanted to get out of VS and try developing in Sublime..
And in doing so expected Sublime to be an IDE and not a text editor, which means they don’t really understand what. text editor is, what’s in scope, or how it functions.
I needed to install Android Studio to get the relevant android build tools, when I was done, I didn't touch android studio, I wrote all my code in Sublime and run a command that uses Android Studio's tools without opening the app. Heck, I could even run an emulator without opening the Android Studio GUI which is comparable to VS. It seems like Windows devs are locked to Visual Studio.
I don't understand why the text editor is coupled to the build process. Visual Studio has, in my opinion, a text editor that leaves a lot to be desired. Multiple cursor support is especially bad, even more so when compared to VS Code multi cursors. Sadly I'm stuck with VS since I'm working on a Xamarin app and I couldn't figure out how to build and run with MS build :(
I read the sentence as “I opened the source code in a different IDE and it fucked with IDE files of the first one”. I don’t use any of the mentioned IDEs so I’m not sure if that’s true or not, but I have ran into it before. I just delete all the files that I wouldn’t check into scm and reimport into my IDE of choice
Point 1 is largely true, Microsoft builds too many competing UI toolkits.
Point 3: You can slim down Visual Studio's install a lot if you're more selective during installation. For example if I only wanted to do .Net desktop application development it is closer to 4 GB and under 10 GB on disk.
Point 4: Is actually the end of the original synopsis on the topic and after it veers off. You successfully built the application.
Now it goes a little off the rails:
Point 5: "The app is extremely resource heavy and way too over-featured." Ok? You didn't say which toolkit, guide, or similar you used nor what you define as resource heavy or in what way it was "over-featured." This is too vague to discuss meaningfully (e.g. Win32 applications built in C++ definitely aren't resource heavy or over-featured for example, and since you didn't clarify even what tech stack was used let alone guide/template this isn't constructive at all).
Point 6: I've read this sentence several times but seemingly you opened an executable in a text editor and that somehow broke your build process? Or something? Was it write-locked by the editor?
Point 7-10: You had a working build pipeline, you broke the pipeline, then decided to start again from scratch in an editor that doesn't have native desktop development support on Windows (because the old editor was "bloated"). You found this process problematic.
So in answer to:
> Why is building Windows apps so complicated
You made it complicated by using unsupported workflows and introducing arbitrary limitations on what was a successful outcome. There's a lot you can legitimately criticize Windows and even its desktop application development workflow for, but this isn't that.