2. Terminal ,pick a folder, `dotnet new wpf`

3. `dotnet run` and you have an (admittedly empty) hello world app

It's telling me it took 1.5s to build the app.

Want to publish the app?

`dotnet publish -o ./publish -r win-x64` which takes a bit longer as it has to download some runtimes (60 seconds max, then cached). Zip up the resulting folder and ta-da you have an application. Just unzip and run the .exe.

If you want a single-file exe (as in completely statically compiled without self-extraction) that's a bit more advanced and requires a few properties in the csproj to configure how to handle native assemblies that expect to exist on disk. If you want it to have no runtime dependencies, add `--self-contained`

As someone who had to develop software in an airgapped enviroment, I'm sending a special "fuck you" to whoever thought this is a good idea. God forbid you have the AUDACITY to not be connected to the internet at all times for any reason whatsoever.

Syncing / uploading then happens once they have signal again. Or in the case of the Garmin I copy the FIT file off by hand when plugging it into my computer.

There are many apps that let you track your run/hike/ride without internet connection.

Personally, I think a dedicated bike computer is best, because then the phone's battery is saved for emergency uses instead of recording a ride. For long rides (8-10 hour) phones won't have enough battery to record the whole ride.

An android app is software.

Not hardware.

No log in, no external services.

Even if it cost money to install, you are just paying for the privilege of being tracked by those folks instead of others.

#appsnotevenonce

- Sygic,

- Topo Map+,

- 2GIS

- Starwalk - Night Sky 2

- and my fav, Genius Map

all works without WiFi, cell coverage, nor NFC/bluetooth

Hardware is cheap, network is reliable. Move fast and break things.

Neither of these assumptions are true, and we're going to have these issues by truckload, until we understand and change our mindset.

At least the website works, even though it transmits the full site for every request...

Scuba diving spots on the world are rarely well covered with internet and even if they are, still many people don't have the roaming/local SIM solution for it.

Guess where you want to use that damn app the most?

Discovered this when I tried to add a WiFi password before connecting to it.

https://www.verizon.com/about/news/how-far-does-5g-reach

> 5G Ultra Wideband network’s signal can reach up to 1,500 feet without obstructions

> 5G can be implemented in low-band, mid-band or high-band millimeter-wave 24 GHz up to 54 GHz. Low-band 5G uses a similar frequency range to 4G cellphones, 600–900 MHz, giving download speeds a little higher than 4G: 30–250 megabits per second (Mbit/s). Low-band cell towers have a range and coverage area similar to 4G towers.

— https://en.wikipedia.org/wiki/5G#Overview

5G is _perfect_ for providing coverage in rural areas, except for the problem that 4G devices are incompatible with 5G networks. Starting 5G rollout in urban areas makes more sense because (a) 5G provides most benefit when clients are close together, and (b) because denser cells make it reasonably economical to maintain 4G coverage in parallel to 5G coverage.

Either way, if we're talking about "coverage" for low-bandwidth stuff like fitness trackers, it's the spectrum that matters more than anything. We can communicate thousands of miles on 1 or 2 watts of LF spectrum using technology that is nearly a century old. Don't need 5G for that, just need to use the right spectrum.

I certainly wouldn't want to ask that the other 99% of the world's developers avoid a feature that's useful to them just to assuage my feelings of envy about the convenience they enjoy.

Nope. The exe files are supposed to do it's thing without internet and no extra effort like it was for a long time.

This does mean that certain programs just won't work, or won't work without some finagling. That's also a feature. The price of control is having to control things.

Granted, most people don't want to pay that price, and prefer convenience. That's admittedly not to my own taste - c.f.) log4j for a good example of why - but I think I'm maybe a little weird there. I certainly don't think there's anything audacious about catering to majority tastes. Maybe just vaguely disappointing.

Saying people prefer one to another hides the fact that they were not given any other option. People will choose whatever default is given and then we may say they everyone prefers that. Or just make the other option (which was normal before) complicated so that nobody wants that now.

Contrast this with e.g. Zig for Windows is a ~60 MB zip file which contains the entire Zig/C/C++ compiler with cross-compilation support for basically everything, and also has complete Win32 headers + libraries in it. There's even DDK headers in there, though I'd expect to do some legwork to build drivers for NT with Zig.

I'm not really sure what you're complaining about here. .net core is split into tiny packages - if that is hard to handle in your very special environment, you get to use special solutions to make it work.

That being said, WinForms is also "just" a Win32 wrapper, I don't see a compelling reason why a similar wrapper wouldn't be possible in pretty much any language. .NET 4.6 is a fine choice too, especially because you're not forced to ship runtime and standard library, as Windows already has both.

We don't even require the internet for building/development. In .net land you require internet to get the dependency you're using the first time. If you want to get them all and distribute/install before you start development, you can totally do that. It's just not the default behaviour.

I get that you have opinions, but you seem to have entirely missed that the runtime is downloaded at build time and included in the bundle. And god forbid if you like doing everything by hand, you don't have to use Nuget and you can manage every last dep by hand, however you like (and you'll likely end up hacking something that is less usable than just setting up a private nuget server, but "opinions").

Yes, technically easy but if their work environment is strict enough to enforce air gapped development, I imagine the bureaucratic process to accomplish such a thing to be a bit less than easy.

Do you even know what an airgapped computer is?

I wouldn't say the campfire was ruined, by my goodwill toward this product certainly was.

Your goodwill deterioration does not matter unless you switch a new a app[1], and a) Make sure that new app can function without internet, and b) Tell your current app developers why you are switching.

So, yeah, your goodwill is irrelevant is you're still giving them money or value. [1] I assume that it's a subscription - most things are nowadays.

Usually you had to dig a bit and could find an "offline installer". Sometimes an "alternate downloads" link is on the initial download page, sometimes you have to good to find a deeper link on the vendor's site.

I always did that just to keep from needlessly reaching out to the internet X times when updating X machines.

And of course, make sure you're getting it from the vendor and not some sketchy download site.

What if I installed the software with the intention to run it without internet, or 5, 10 or 100 years in the future?

You can download all versions of Android if you want, but i doubt that you would want that.

And yes, this sucks. But if you want freedom, there are other OSes (or even other dev tools) where you can have it.

This is important because I support each release of the distribution for up to 10 years, and have some customers who may need to build it in an air-gapped environment.

[0] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...

Personally, I just run things in network namespaces with "ip netns exec offline|wireguard $COMMAND" to restrict net access.

I thought about using a network namespace, but that would make things more complicated since I would need to re-call my shell script to pick-up where I left off (because it requires creating a new process). I initially tried to implement this using network namespaces, but you cannot "unshare" the current process, you must spawn a new process.

With dropnet I can do

      download()
      enable -f ./dropnet.so dropnet
      configure()
      build()
      install()

In this particular scenario, my first thought was "shoulda used golang".

I hear tell that since then (1+ yrs ago) matters have improved in the realm of MS standalone apps (well, maybe just cmd line apps).

oh, and the exe is round about 65mb compared to a golang ~5 or 6mb

You can even prefetch popular libraries: https://crates.io/crates/cargo-prefetch

And you can likely mention it as an explicit dependency in your csproj so that you can download it on first restore.

Also, when you write something on those environments, you know users cannot install a runtime. So you get in touch with IT teams to ensure which version of runtime they are deploying. If and only if you have to update it for proper reasons, then they can deploy newer versions to the clients. For all or for a specific user base. This is how it works.

Without an actual business case or a security concern, you don't just go from a runtime to another, let's say 4.8 to 6.0. So yes, development in airgapped environments is PITA. But it's the same with Java, Python, Perl, etc. That's not the fault of the runtime but the development environment itself.

That's exactly what you have to do here.

I understand OC issues with the difficulties associated with using M$ tools with limited internet but wonder if the "Air Gapped" example may be a bit extreme.

Being required to work from home while still meeting an employers' secure network policies might be more common.

The end result is a Golang-like, single binary experience that runs on many platforms easily and rapidly.

Though I can master a lot of programming languages, I miss C# the most especially on async/await and LINQ. Rust is what I'm favourited in second places with a lot of similarities of C#.

[1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...

But to this day, nobody knows what data your system telemetries to Microsoft. Not the data they talk about in the 5-10 page license. Instead, the data mentioned in the 55 page doc about what you agree to send them, that they refer to from the MS Software License...

Like every other dev system, connect, either download offline installers for everything (they exist), or get your system running, then you can dev offline all you like.

You don't need to "be connected to the internet at all times for any reason whatsoever". You need it once.

What I miss is the old model for installing software. Give me the yearly ISO, optionally provide a service pack or two if some huge problem went under the radar in testing.

If you don't want it to download anything then you use the `dotnet publish --no-restore` flag, which is used a lot in CI/CD pipelines. If you don't have the package dependencies cached it will then simply fail.

The internet exists, the industry has evolved, software has dependencies, and yes you have to download them (just like you had to download the SDK ISOs back in the day). But it's just one command, run it and get it over with, and after that up-front one-time pain you'll have a nice offline workflow.

I should be able to take my computer to a remote cabin with no Internet, and use all the software on it. The only software I'd expect to not work is software whose purpose is to access data stored on the Internet, like web browsers. I don't think this is such a crazy user expectation.

For many, it is not so black and white. Internet connections are spotty, slow, or expensive. In GP’s case, there is no internet.

Like I said, you are welcome to ignore those users. But your ignorance (I don’t mean that in a derogatory way) doesn’t change their situation.

That is easily doable. However users often don't want a copy of a large runtime for each and every program they use, so it often makes sense to move common things (like DLLs, runtimes, your OS) to libraries that can be shared.

You can easily make dotnet apps in either flavor to your liking. And not every developer is going to make their apps to appeal the your needs.

In days gone by we used to have truly standard libraries and runtimes, in the sense that they came with your build tools out of the box and so were available everywhere. Host platforms similarly provided basic services universally. Documentation was often excellent and also available out of the box.

In that environment, writing "Hello, world!" meant writing one line that said do that, maybe with a little boilerplate around it depending on your language. Running a single simple command from a shell then either interpreted your program immediately or compiled it to a single self-contained executable file that you could run immediately. Introducing external dependencies was something you did carefully and rarely (by today's standards) when you had a specific need and the external resource was the best way to meet that need.

Some things about software development were better in those days. Having limited functionality in standard libraries and then relying on package managers and build tools where the norm is transitively installing numerous dependencies just to implement basic and widely useful functionality is not an improvement. The need for frameworks and scaffolding tools because otherwise you can spend several hours just writing the boilerplate and setting up your infrastructure is not an improvement.

Microsoft could do a much better job onboarding new developers.

Hell just recently they were trying to take away hot reload to keep that feature as a paid feature only part of VS

The fact this edition exists does not change my point, or really add anything of value to the conversation

I only really started liking .NET when I stopped using visual studio a few years ago.

If you want an installer BTW, use "Wix".

If you are eligible for VS Community, do give it a go: https://visualstudio.microsoft.com/vs/community/ since that has the WPF designer in (the WinUI3 designer is inexcusably broken)

I just tried VS2022, and the UI designer for WinUI3 is completely non-functional? What is the recommended approach to lay out the UI pages these days?

- ignore Winui3 and do it in WPF (fewer controls, deprecated, actually works)

- do it blind in XAML, possibly with the aid of a piece of paper. Or the "live view" in VS if that works. (Live View is the suggestion given on the github issue for "designer doesn't work", fwiw)

- do it in the UWP designer, then s/Windows/Microsoft/ in the control namespaces

I hope SwiftUI and flutter will be able to make it at least a little bit better.

This. This is what's wrong. Why is single-file exe "a bit more advanced". In early 2000s Delphi could build a single file exe in seconds, and that was the default behaviour.

What changed since early 2000s that having an exe is a) advanced and b) requires manually fiddling with some unspecified properties in the abomination that is a csproj file?

Because that's how it works for very every single interpreted and bytecode compiled language?

And the thing that changed in the early 2000s was a massive shift toward using interpreted and bytecode compiled languages.

If we're specifically talking .NET, the thing that changed since the early 2000s is that creating a self-contained executable became possible in the first place. On Windows, .NET *.exe files were still run by an outside runtime, it's just that, since Microsoft owned the whole platform, it was easy for them to hide all that behind a curtain, ensure .NET is preinstalled with Windows, etc. The design constraints changed when .NET became cross-platform. OS X and Linux require a bit more (or at least different) finagling in order to achieve good user experience.

I went ahead and searched for C# executable around 2005-2006. Guess what, this wasn't even a question then. Because, apparently, building an .exe was also the default setting for C# projects in Visual Studio.

So. What changed?

> If we're specifically talking .NET, the thing that changed since the early 2000s is that creating a self-contained executable became possible in the first place.

It was always possible.

> On Windows, .NET .exe files were still run by an outside runtime

1. We're literally in the thread to a question about Windows apps. On Windows

2. If you've ever did anything on Windows such as played a game, you'd know that you almost always need something external to run: be it msvcrt (c++ runtime) or clr.

> The design constraints changed when .NET became cross-platform.

What you mean is: it's still perfectly fine to create a standalone executable, but for some reason it's now called a "more advanced operation". The thing that's changed is that now it's hidden behind a ton of inconsistently named parameters

They were much more comparable to an "executable" Python or Perl script where the OS knows to look at the hash-bang line to figure out what interpreter to use to run it. If you try to execute one of those .NET .exes on a computer that doesn't have a suitable .NET run-time installed, you'll get more-or-less the same error as you'd get trying to run a Python script on a computer that doesn't have Python installed.

The part that was being criticized a few comments up was about how to create self-contained .NET apps with the runtime bundled in and everything. Specifically, these guys: https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ... That kind of executable simply did not exist in the old Windows-only .NET Framework; it's a feature that was first introduced in .NET Core 3.0.

Just as you would try to execute a program written in C++ (and not statically linked etc.) on a computer that doesn't have a msvcrt runtime installed.

This is not a new thing. Nor is it a "more advanced".

It feels like you're getting too hung up on "exe". The important part is standalone vs. not standalone.

I for one don't want every application to include 100's of MB of standard components that every other such app also brings (such as Electron style apps). I'd much rather have an app tell the OS to fetch missing pieces once, and once only, then future apps share.

And this also mitigates a significant source of security holes. Nothing like linking everything and the kitchen sink so your system is riddled with unknown, hidden vulnerabilities in binaries.

For example, I recent worked on tools to search for such things - they are EVERYWHERE. OpenSCAD, for example, includes a ssh engine, which has known vulnerabilites, but OpenSCAD does not list them. I found thousands and thousands of embedded binary libraries in applications with known and unpatched vulnerabilities.

Too bad all those didn't use a decent package manager, allowing systemwide updates to common functionality. I suspect the future is more components, not less, for these reasons.

Also please dont lump interpreted languages with C#. At least with interpreted languages, once you have the runtime on your computer, you can have a single script file to work with. With C#, you STILL have to have the runtime on your computer, then after you "compile", youre left with a folder of one EXE and literally over 100 DLL.

The main difference is that Python installs them globally (or at least thinks it does, if you're using virtual environments), while .NET apps isolate themselves from each other.

Also, let's make a fair comparison. Is that hypothetical Rust application of yours depending on literally 100 crates? If so, what is the size of your binary?

I love Python, but I cringe whenever someone asks me why a Python program isn't running properly on their machine. Obligatory xkcd: https://xkcd.com/1987/

In fact, composer uses dependencies managed by itself in their sources. Then it gets packaged and distributed as a single file that includes all dependencies (composer.phar). That single file can be run by php as if it was any regular php file (including executing it directly and letting your system detect the required interpreter through the shebang).

https://www.php.net/manual/en/intro.phar.php

No you don't. If you'd rather increase the download size for the user then you can turn on self-contained (include runtime) and single-file app.

1. Build it runtime dependent: ( which requires the NET 6 runtime to be pre installed ) on your computer in order to be able to run: You get a single exe file.

2. Build it self contained: You get a directory with a bunch of dlls and one exe But no runtime needs to be installed on the target computer

3. Build it self contained + single exe: You a get a single exe that embeds all those dlls and unpacks them in memory ( since net 6, in net 5 it would copy them to a temp directory )

4. Build it using AOT Mode: You get a single, statically linked exe. This is probably the closest to a standard Rust (statically linked) build. However AOT mode is not yet official and requires some fiddling still, but should become stable for NET 7 next year. And you loose out on some features obviously like runtime code generation

The Python people stuck in venv hell would probably think otherwise.

That means that by default you can't do tree shaking, which means you would end up with enormous exes, which will probably annoy the type of people who want a single exe.

The bit more advanced is to tell the compiler which types you might want to reference by reflection so that it can shake the rest out of the tree.

The old Delphi-based version of Skype fell into that category. Thinking of that example, I can understand why some people think modern software is decadent.

Short story: developer interests unfortunately don't always align with tool builder interests.

It's really easy/simple to change an application to adjust for a different client this way.

I'm not sure I know any frameworks that easily support arbitrary native .dll/.so inside the application executable.

I'm talking about creating a single-file application, which is just an end-user nice-to-have if you aren't using an installer or deployment system.

Don't most applications have a bunch of ancillary files? I rarely see installed applications on any platform that are a single file.

.NET Core is cross platform, it was created with ASP.Net as the driver and web development is not about exe files. "dotnet run" runs your code, on any platform, that's one of the default intended ways to run code. If you want a platform-specific executable you've done more work and made the code less general. If you also want to package the entire .Net framework into one binary on any platform, why is it unbelievably impossible to understand that this is more effort and desired by fewer people, so isn't as easy to do?

Strategic decision from Sun and Microsoft that has crippled software for 2 decades already.

The C# team says "this is the new best practice" while VS still drives you to The Old Way all the time.

https://news.ycombinator.com/item?id=28972431

There was a whole fiasco where the dotnet/C# team were forced to remove features from dotnet in order to sell more copies of Visual Studio. Later, Microsoft lied through their teeth and said it was some kind of sprint-planning scoping error, even though the development work was already done.

Full disclosure: I know what I am talking about

Except, everyone else cares about everything else .NET Framework has been used for the last 20 years.

This was quite telling on the .NET 6 release with its minimal APIs to compete against Python and JavaScript "hello world" apps. As soon as one scales beyond that, it is back to the old MVC model.

Isn't WPF getting phased out tho?

wpf is a stack for slow bloated apps (200mb for a hello world and 300 dlls)

even electron is lighter than this.. electron..

microsoft needs its swift + swiftui moment

Meanwhile, say what you will about the web ecosystem, I've given interns/jr devs tickets like: see if you can get this webapp running in electron, and maybe figure out how to do push notifications and save data locally. Two days later the project is done. A week later, the app is ready to install.

I think the real reason I quit doing meaningful amount of native GUI development a decade ago was velocity. The developer experience with iOS is probably about the best of the major GUI platforms, but even that is rife with tarpits of tribal knowledge and gets really complicated to release an app due to the whole App Store experience.

It's depressing to watch this trope start to bleed over into HN.

After all it's neither going to be popular because it's a popular sentiment nor is it particularly likely to be something interesting/relevant to get upvotes on merit. It's just going to be an unpopular opinion that gets ignored.

But seriously Electron is so many times better than writing native apps .. or even trying to find the documentation for how to do _one single thing_ in a native app the way you want to.

You are less likely to read the truly unpopular opinions but yes I agree, seems like a cheap way to gain popularity.

I'd say you're right about the GUI shitshow, and the web ecosystem is just a slightly different kind of shitshow.

There's a huge amount of tiny chores with web development, that if you hadn't learnt how to do them in 1.5 seconds 5 years ago, would take you 2-3 days to figure out.

There are a hundred small chores that must be done to build and launch software on the web that you have to learn before you get it going.

I strongly doubt desktop doesn't have the exact same volume of inane things as webdev.

If you insist on using the new hotness being offered for any platform (web, native, whatever), then sure, you're doing to see this. But in the web context, you reference the DOM APIs that are stable ... in the same way that Qt, GTK (or even Cocoa) have been. New APIs for web dev show up monthly, but you apparently manage to not keep switching from one to the other. Why would you do the same thing for native dev?

But the number of Windows native app APIs is insane, and every year I try to learn how to create an XCode basic app and it’s different. Creating a simple app with HTML and JS however is the same as it’s always been.

https://ardour.org was first ported to then-OSX in 2006. Almost nothing in the codebase that relates specifically to now-macOS has changed in that time.

XCode is a tool, not a platform. Cocoa is the platform, and it changes very little and very infrequently.

When we first ported Ardour to OSX/macOS, it was abundantly clear that XCode was a non-starter in terms of technology, partly because it was single platform, and partly because its scope was too large - as Unix-based developers we understood the merits (and occasional pain) of more modular toolsets. So I found a handy guide to writing "nibless applications" that completely removed XCode from the picture (along with some Cocoa boilerplate code that isn't actually required). As a result, we've continued to interact with the stable API core of Cocoa, even as Apple dither around the edges.

Apple (and Microsoft and .... ) are not your friends. They want you to build software for their platforms, but beyond making that possible in some way, their incentives do not align with yours in any substantive way (partly because they make software too, and have their own API goals and needs that may/will conflict with yours). If you don't understand this, you're inevitably going to have the sort of experience you describe above.

By the way, a blog post on how to create Nibless apps would be invaluable.

I'm not sure if this is the source I used, because the date is a little late, but it seems very thorough and excellent:

http://lapcatsoftware.com/blog/2007/05/16/working-without-a-...

Qt is native in that sense, just as much as any other toolkit designed for the same purpose.

Native GUI is more cplicated nowadays too, but I don't expect it to change too much - controlling layout using CSS+HTML is harder than in most (if not all) native GUI frameworks.

I still cannot comprehed how we ended up with the shitshow that is CSS/HTML. Even Javascript nowadays is a workable language ( or otherwise typescript ) WebAssembly is great... but the actual UI Layer with the DOM and CSS .... just a nightmare

Every time i have to work on something a bit more complex on the browser, i ponder of writing my own UI Toolkit based on Canvas/WebGL or WebGPU and just draw everything myself

For me its a no go to have a language that's bascially a dead end outside of one specific ui framework.. Seems like a solution in search of a problem.

What other framework doesn't maintain 60 fps in its hello world?!

Flutter works great on mobile and desktop though, I shipped multiple apps using it and currently writing a desktop app.

Any desktop app I make that needs a GUI gets written in Java. Swing is antiquated but doesn’t change every year like everything else keeps doing. I use an XML UI definition language (Swixml) to make it RAD. With a modern look-and-feel package it looks great, runs fast on modern hardware, works the same on Windows/Mac, is easy to deploy, and most importantly: I know it will work basically forever.

So you had an app that was already written, ported it to electron (designed to make the port as painless as possible), and you note that this is easier than writing it from scratch with non-web APIs? This is not exactly suprising, is it?

In a parallel universe, a junior dev who only learned Qt would have same amount lot of trouble making websites.

True, and had we tried to port to native, that intern would have given up. Most of the business functionality was in a REST api, so porting to native was something that was doable, but the level of effort would have been extreme. Oh, and had we wanted native on Mac, Windows, Linux, Android and iOS... well... that's 5x jumbo right there.

You can sort of kind of pull this off with a relatively limited web app, where the interactions are limited to tapping (since there's generally touch interaction on the desktop) and the fluid layout possibilities of modern CSS give you some chance of coming up with a general design that can work sort of kind of OK across all browsers on all platforms.

But try this for a more complex app, the sort that has been traditionally desktop only, and I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms, regardless of the actual toolkits /technology you are willing to use.

Android and iOS represent the majority of devices your software can be run on. They are ubiquitous, and also very dependent on a native UI frameworks that are a somewhat better developer experience than their desktop counterparts, but only because the years of accumulated cruft are less. Incidentally, Android actually does have a desktop mode for it's GUI. That said, users rarely use the desktop Android GUI.

> You can sort of kind of pull this off with a relatively limited web app

I've had better luck with electron and PWAs on the desktop than non-native mobile tooling. This is largely because non-native mobile frameworks often don't have access to the same libraries - or the abstraction layer loses fidelity in trying to be cross platform. There's really no QT grade multiplatform tooling on mobile. There's some promising starts.

> I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms

It's hard to get a decent GUI on both Android and iOS that doesn't have a lot of rough edges with cross platform frameworks. They are coming along, but it's still just not quite there yet.

Flatpaks make distribution a non-issue too.

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.

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.

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.

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.

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'.

> Your experience is expected for the framework.

This is worded like a defense? But agreeing with OP that the situation is awful?

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.

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.

Everyone uses VS, Rider or VS Code.

Edit: looks like there is an extension for C# and C++

Even C/C++ apps. It's actually a pretty great visual debugger on Linux for that reason.

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..

WPF is nice, but it's not developed much anymore and lacks basic features that people have come to accept (great touch support, smooth scrolling). And the successor technologies are all a mess, driven by Microsoft's internal politics more than by any coherent strategy. I tuned into a few streams of Microsoft's developer conference last year, and no fewer than three different UI libraries, developed by three competing divisions, where announced as "the future of app development on Windows". I can guarantee that only 0-1 of those will survive, so good luck betting on the right one.

The only real recommendation I can give is to do as Microsoft does, not as they say. So while they tell everyone to use UWP, WinUI, MAUI or whatever, all of their own new apps are written in Electron. Decide what that means for yourself.

When you look at Teams or Outlook it seems even MS themselves doesn’t know anymore how to develop solid and reliable desktop apps.

My advise is to go either qt, electron or web. Preferrably web IMO because there is a clear path to the future.

Commercially, it works. Unfortunately, it's slowly killing the desktop computing experience. Unlike Apple, they don't even have a real interest in shifting hardware, so they can happily treat the desktop market like dirt.

It's weird, seeing MS effectively strangling their own baby, but I guess Wall Street is happy.

The root cause of the SDK fragmentation is because Microsoft sees diminishing returns for Windows.

After Silverlight failed to gain adoption, they started losing interest in the desktop. When Windows Phone was killed, there was even less interest in UWP.

It's a shame because .NET is quite nice.

I agree with the first part, but IMO the situation would be better if they actually dropped frameworks instead of having them all in a limbo state.

Meanwhile on Windows there was close to zero effort on making the system usable from a CLI before half a decade ago. There are still lots of tasks that require you to log in on a GUI, for instance. Applications started in GUI mode have no console attached, so you have zero diagnostic messages when started in a CMD. The entire command line tool situation is a complete mess, and it's clearly meant that msbuild and friends are actually meant to be invoked by Visual Studio instead of being used from a CLI.

Until a few released ago there still was no non-hacky way to get a development PowerShell, because all the various `vcvars` scripts were only batch files.

The complexity of using XML files in project descriptions just complicates things, and ironically I've seen several occasions in which msbuild just tells you to change a settings using Visual Studio (instead of telling which CLI toggle you are supposed to use).

My two cents is that IDEs and GUI told may be convenient but they should never be the default way to do anything, especially with development tools.

The process of making GUI programs used to be very straightforward. If anything, in the last 10 years, Microsoft has improved the CLI experience by leaps and bounds, while at the same time it made making GUI software significantly worse.

Making CLI programs on Windows was never a big problem. There was always a way depending on which language you chose, and even if you wanted to POSIX you could with Cygwin. Sure, it wasn't Linux but that was the nature of the system. Now you don't even need hacks.

Making GUI software, however, is currently very... weird. Making GUI software, especially on Windows, was historically very simple and never required any CLI, let alone a good one.

I also disagree that making GUI apps in Windows is a "byzantine and convoluted process". It is not, and it never was. You can create a simple GUI app with a single .cpp file and compiler command. If you want to use Winforms you could draw the windows. VB6 before as well. WPF on Visual Studio was also very simple.

The only part that I agree is still unfinished is the .NET CLI-only experience, which the OP complained about. But that part also kinda sucks on Linux and Mac. If you use Visual Studio it works well.

The whole issue with native GUI apps in Windows currently is that nobody, not even Microsoft, knows the way forward for apps. Apple knows: it's Swift and Cocoa for Mac. The Linux world seems to be moving towards Wayland (I know I'll get some smart-ass responses on that). iOS and Android also have a happy path.

On Windows? There are 6 or 7 different APIs and 20 different ways to start an App, and none of them super maintained, well documented or even officially favoured by MS. Sure, Win32 might not be going away, but some things are better in WPF. Wait oh no WPF was replaced by WinUI. But what's that WinForms thing? And this MFC thing that got recent updates?

You're right that the CLI is an afterthought. So stop using it. If you want to build Windows apps, you've got to do it the Windows way, or it'll be a world of pain.

MSBuild isn't _that_ bad once you learn its terminology. Get the msbinlog viewer, an absolute hidden gem of a diagnostic tool. https://msbuildlog.com/

It's definitely huge tool, but it allows you to do a lot of kind of developments.

I think it's very decent tool if you want to do C# development, especially when you want to have reliable intellisense and strong debugging tooling

(expression evaluation at fly, changing code at fly, moving to different lines during debugging, conditional breakpoints)

The most valid point is that Microsoft keeps churning out new UI frameworks that all seem to die quickly, with some still staying alive.

Running compilers in the command line on Windows has always been possible and it is trivial these days.

That goes for both (MS) C++ or .Net.

Hitting F5 "build" is easier than using the command line. That does not mean the command line in not well supported.

Visual Studio will generate a script you can use to build the projects from the command line for your projects

Here is an example of a minimal Win32 app written in C https://docs.microsoft.com/en-us/windows/win32/learnwin32/yo...

It is tiny and uses nearly no resources. The code is about the same as it was 10 years ago.

Using Winforms with C# it is trivial to create a minimal Windows application that is small and uses nearly no resources. (just but a button on the canvas, hit F5).

Any decent code editor can be easily adapted to work with the C# or C++ Microsoft compilers for builds.

Visual Code offers deep support for C# https://code.visualstudio.com/docs/languages/csharp

This article seems to outline how to get C# support in Sublime (I am not a Sublime user so I dont know how well this works) https://www.quora.com/How-do-use-sublime-text-editor-for-cod...

I want to build a WinUI3 app, and that seems to require 56mb and a hundred of mbs of dependencies just to show a button with "Click Me" on it.

I did include instructions for configuring both Visual Code and Sublime in my comment.

How to create a simple and minimal WinUI app here: https://docs.microsoft.com/en-us/windows/apps/winui/winui3/c...