> The build.bat above isn’t just a helper script; it’s a declaration of independence from the Visual Studio Installer.
I am so fed up with this! Please if you're writing an article using LLMs stop writing like this!
I fixed Windows native development
121–130 of 406 posts
Re: I fixed Windows native development
#122I'll just keep using Mārtiņš Možeiko's script, portable-msvc.py, that this tool is based upon. It does everything this does, except a lock file and the autoenv. I'm not particularly interested in the former, and definitely not the latter.
https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cd...
Re: I fixed Windows native development
#123Earlier quoted context omitted.
Visual Studio does have that functionality, via vsconfig files: https://learn.microsoft.com/en-us/visualstudio/install/impor...
Doesn't look like it's versioned, or installs Visual Studio itself.
For Visual Studio components that are versioned (like the C++ compilers/libraries), the version number is included in the component name.
You still have to install the tool that processes pyproject.toml so that doesn’t seem fair to hold against it. You are right that you still have to know whether to install 2022 or 2026.
Re: I fixed Windows native development
#124Re: I fixed Windows native development
#125Earlier quoted context omitted.
Which has been fixed on .NET 5 and later. .NET Framework should only be used for legacy applications. Unfortunately there are still many around that depend on .NET Framework.
Since .NET 10 still doesn't support Type Libraries quite a few new Windows projects must be written in .NET Framework. Microsoft sadly doesn't prioritize this so this might still be the case for a couple of years. One thing I credit MS for is that they make it very easy to use modern C# features in .NET Framework. You can easily write new Framework assemblies with a lot of C# 14 features. You can also add a few inter…
Most likely never will, because WinRT is the future and WinRT has replaced type libraries with .NET metadata. At least from MS point of view.
The current solution is to use the CLI tools just like C++.
However have you looked into ComWrappers introduced in .NET 8, with later improvements?
I still see VB 6 and Delphi as the best development experience for COM, in .NET it wasn't never that great, there are full books about doing COM in .NET.
Re: I fixed Windows native development
#126Earlier quoted context omitted.
Which has been fixed on .NET 5 and later. .NET Framework should only be used for legacy applications. Unfortunately there are still many around that depend on .NET Framework.
.Net Framework 4.8 has a longer life cycle as the current .NET version
It does, but current versions can be shipped with the application.
Thus this should be less of a problem.
Re: I fixed Windows native development
#127Actually not that complicated: You simply check in a global.json [0] where you specify the sdk and workload versions. Then you also specify target platform sdk versions in the .csproj file and VS will automatically prompt the developer to install the correct toolchain. [0] https://learn.microsoft.com/en-us/dotnet/core/tools/global-j...
global.json is only for .NET toolchains.
What you’re actually wanting here is .vsconfig https://learn.microsoft.com/en-us/visualstudio/install/impor...
Re: I fixed Windows native development
#128Toolchains 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…
> Toolchains on linux are not clear from dependency hell either - ever install an npm package. That's where I stopped. Toolchains on linux distributions with adults running packaging are just fine. Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine. I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain pa…
The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.
And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it.
Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?
Re: I fixed Windows native development
#129Nix on Windows when...
Since roughly September 2022 with the release of WSL 0.67.6!
Have you actually attempted to use it recently? Are you familiar with the WSL1 bugs that surface when running random Linux distros?
(To be clear, I haven't tried this with Nix, but I have with other distros.)
Re: I fixed Windows native development
#130[dead]