3 ms·

I think the main culprit for the whole situation - that is, the fact that building anything on Windows is a byzantine and convoluted process - is the fact the w

I think the main culprit for the whole situation - that is, the fact that building anything on Windows is a byzantine and convoluted process - is the fact the whole OS was designed with CLI as an afterthought. On UNIX the CLI is always forefront and center - you don't really have "GUI" apps, all apps are console apps and they may connect to some sort of Window server and draw windows. 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.

ratww 5y ago
I completely disagree with this take. 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?
ufmace 5y ago
I think you've got this all wrong. Building Windows apps on Windows is really simple as long as you do it the Windows way instead of trying to cobble together a way to make it as much like the Unix way as you can. Abandon all thoughts of using a CLI for any part of the build process, install Visual Studio, and build with it using the default starter projects. It will just work. 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.
- pjc50 5y ago
  You do need a CLI to do CI, which is necessarily headless. The toolset you need for this is the "Visual Studio (year) Build Tools". https://community.chocolatey.org/packages/visualstudio2019buildtools https://community.chocolatey.org/packages/visualstudio2019bu... 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/ https://msbuildlog.com/

ratww 5y ago

I completely disagree with this take. 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?

ufmace 5y ago

I think you've got this all wrong. Building Windows apps on Windows is really simple as long as you do it the Windows way instead of trying to cobble together a way to make it as much like the Unix way as you can. Abandon all thoughts of using a CLI for any part of the build process, install Visual Studio, and build with it using the default starter projects. It will just work. 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.

pjc50 5y ago
You do need a CLI to do CI, which is necessarily headless. The toolset you need for this is the "Visual Studio (year) Build Tools". https://community.chocolatey.org/packages/visualstudio2019buildtools https://community.chocolatey.org/packages/visualstudio2019bu... 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/ https://msbuildlog.com/