Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager. Remember patching openSSL when heartbleed came around (libssHELL).

Visual studio is a dog but at least it's one dog - the real hell on windows is .net framework. The sheer incongruency of what version of windows has which version of .net framework installed and which version of .net your app will run in when launched... the actual solution at scale for universal windows compatibility on your .net app is to build a c++ shim that checks for .net beforehand and executes it with the correct version in the event of multiple version conflict - you can literally have 5 fully unique runtimes sharing the same .net target.

This is harder than what I do. Just install LTSC Visual Studio build tools from [1], then chuck this in a cmd file:

    cl yourprogram.c /link user32.lib advapi32.lib ... etc etc ...

The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though. see: https://learn.microsoft.com/en-gb/visualstudio/releases/2022... - you should use these if you are not a single developer and have to collaborate with people. Back like in the old days when we had pinned versions of the toolchain across whole company.

[1] https://download.visualstudio.microsoft.com/download/pr/5d23...

While this is great - Visual Studio installer has a set of "command-line parameters" for unattended installs.

You can then build a script/documentation that isolates your specific requirements and workloads:

https://learn.microsoft.com/en-us/visualstudio/install/use-c...

Had to do this back in 2018, because I worked with a client with no direct internet access on it's DEV/build machines (and even when there was connectivity it was over traditional slow/low-latency satellite connections), so part of the process was also to build an offline install package.

I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs.

I don't understand how open source projects can insist on requiring a proprietary compiler.

Alternatively, there's this:

Install Visual Studio Build Tools into a container to support a consistent build system | Microsoft Learn

https://learn.microsoft.com/en-us/visualstudio/install/build...

One day I decided to port my text editor to Windows. Since it depends on pcre2 and treesitter, these two libraries had to be provided by the system.

In the span of ~2hrs I didn't manage to find a way to please Zig compiler to notice "system" libraries to link against.

Perhaps I'm too spoiled by installing a system wide dependency in a single command. Or Windows took a wrong turn a couple of decades ago and is very hostile to both developers and regular users.

Is this post AI-written? The repeated lists with highlighted key points, the "it's not just [x], but [y]" and "no [a] just [b]" scream LLM to me. It would be good to know how much of this post and this project was human-built.

What we did for out build agents was to just install the required version of build tools via chocolatey. But cool approach!

* Is this allowed per VS' ToS?

* I wonder if Microsoft intentionally doesn't provide this first party to force everyone to install VS, especially the professional/enterprise versions. One could imagine that we'd have a vsproject.toml file similar to pyproject.toml that just does everything when combined with a minimal command line tool. But that doesn't exist for some reason.

For big C++ projects, the .vsconfig import/export way of handling Visual Studio components has worked well for the large teams I'm on. Tell someone to import a .vsconfig and the Visual Studio Installer does everything. Only times we've had issues is from forgetting to update it with components/SDK changes.

Perhaps winget is enough?

winget install Microsoft.VisualStudio.2022.BuildTools

I was just setting up a new machine and was setting up the Rust environment. The very first thing rustup-init asked was to install Visual Studio before proceeding. It was like 20-30gb of stuff installed before moving forward.

This tool would be a great help if I knew beforehand.

Thank you, this might be a great way to improve the developer experience in the conda/conda-forge ecosystem.

> No Visual Studio installation. No GUI. No prayer. Just a script that does exactly what it says.

Please add also the support for the clang-cl[1][2].

[1] https://clang.llvm.org/docs/MSVCCompatibility.html

[2] https://clang.llvm.org/docs/UsersManual.html#clang-cl

This is amazing.

At $workplace, we have a script that extracts a toolchain from a GitHub actions windows runner, packages it up, stuffs it into git LFS, which is then pulled by bazel as C++ toolchain.

This is the more scalable way, and I assume it could still somewhat easily be integrated into a bazel build.

It starts by not looking into Windows through UNIX developer glasses.

The only issue currently plaguing Windows development is the mess with WinUI and WinAppSDK since Project Reunion, however they are relatively easy to ignore.

Were you around before the new installer came out? It was light speed compared to what was before!

And here I was messing with MingW64…

This is fantastic and someone at Microslop should take notes.

Say what you want about coding agents, when the cost of writing code goes to near-zero, the cost of wrangling tools becomes a much bigger fraction of development effort. This is an amazing opportunity to address long-standing frictions.

next, wrap it with wine and eventually share a bottle/winetrick

So this fixes the problem when msvc is the required compiler. Does the zig C++ compiler bring anything to the table when clang is an option?

Nix on Windows when...

I havent run into this problem yet... but my oldest .net software is only 1 year old... Is this something that happens over the course of a few years?

Another option is explore winget and chocolaty. Most build tools and compilers can be installed via the command line on windows. Ask your favorite LLM to create a powershell script to install them all.

This is a serious quality of life improvement for people forced to deal with Windows! Great job.

I'm just asking, but is there really a need for a native programs anymore? Where I worked a decade ago, we started porting all our native programs over to the browser and this was when MVC beta was just being released. At this point with Electron and Tauri, is there even a need to write a native program

Now with AI, I would think that porting a native program to the browser wouldn't be the chore it once was.

Is this even legal?

At the risk of being that guy, I haven't had any issues onboarding people onto native projects written in Rust. rustup does a great job of fetching the required toolchains without issue. I'd imagine the same is also true of Go or Zig.