ハクソク

世界を動かす技術を、日本語で。

Windowsネイティブ開発を修正しました

99日前原文(marler8997.github.io)

概要

Visual Studio のインストール依存がWindows開発で大きな障壁となる現状 msvcup というCLIツールにより、MSVCツールチェーンとSDKの導入を簡素化 バージョン管理 ・再現性・クリーンなアンインストールが可能 スクリプト化 により、どのWindows環境でも同じビルド手順を実現 本記事 では、問題点の整理とmsvcupの使い方・メリットを解説

Visual Studio依存の苦悩と現状

  • Visual Studio のインストールを依存関係として指定する必要性
  • GitHub Issues がコードでなく、インストールやビルドのトラブル報告で埋まる現象
  • C++開発 で必要なWorkloadやビルドツール、SDKの細かい指定が必要
  • 巨大なIDE （50GB超）のインストール負担
  • 選択ミス で不要なコンポーネントのインストールやビルド失敗リスク
  • Linux のようなシンプルなパッケージ管理との対比
  • 全てが一体化 されたVisual Studioエコシステムによる混乱
  • バージョン管理不能 ・環境汚染・アンインストールの煩雑さ
  • コマンドラインビルド も専用プロンプトやバッチスクリプトが必要
  • ビルド再現性の低さ や「Works on my machine」問題

msvcupによる新しいアプローチ

  • msvcup はMSVCツールチェーンとSDKの導入を自動化する軽量CLIツール
  • バージョン管理 ・ディレクトリ分離・高速化・クロスコンパイル対応
  • スクリプト一発 で依存環境の自動インストールとビルドを実現
  • curl/tar が使えるWindows 10以降なら追加インストール不要
  • ロックファイル による再現性確保
  • アンインストール・再インストール も簡単
  • autoenv コマンドで環境変数設定も自動化
  • CMake との連携も容易

msvcupを用いたビルドスクリプト例（hello.c）

  • hello.cとbuild.batを作成し、以下の手順で実行
    • msvcup.exeがなければ自動ダウンロード＆展開
    • 必要なMSVCツールチェーン・SDKをバージョン指定でインストール
    • autoenvで環境セットアップし、clでビルド
  • Visual Studioのインストール不要
  • 依存関係が明示的 で、どのマシンでも同じビルドが可能
  • レジストリやグローバル環境を汚さない
  • 2回目以降は高速実行 （ミリ秒レベル）

仕組みの詳細

  • Microsoft公式のJSONマニフェスト を解析し、必要なパッケージのみをCDNから直接ダウンロード
  • C:\msvcup**以下にバージョンごとに分離して配置
  • autoenv でラッパー実行ファイルを生成し、環境変数のセットアップも自動化
  • toolchain.cmake も自動生成し、CMakeプロジェクトにも即対応

CIや大規模開発での活用例

  • Tuple （ペアプログラミングアプリ）でCI・開発環境に統合
  • WebRTCなど多数のC/C++プロジェクト を同じ環境でビルド
  • x86_64/ARMビルド も容易に実現
  • 誰でも同じツールチェーン・SDKを利用 できる環境を確立

msvcupの主なメリット

  • バージョンごとにディレクトリ分離、複数バージョンの同時運用が可能
  • クロスコンパイル対応、必要なツールは自動で全て取得
  • ロックファイル対応、再現性の高いビルド環境
  • インストール・環境構築が高速、不要な作業が発生しない場合はミリ秒で完了
  • 「自分の環境だけ動く」問題の解消、レジストリやパス探索不要
  • 環境がコードで定義 され、移植性・再現性が向上

制限事項

  • Visual Studio IDE やMSBuildプロジェクト、C++/CLIなどは未対応
  • コアなコンパイルツールチェーン に特化した用途向け

実例：raylibのビルド

  • msvcup とスクリプトだけで、クリーンなWindows環境でraylibをビルド可能
  • Visual Studio不要、GUI操作不要、完全自動化
  • 必要なツール・SDKのインストールからビルドまで一括実行

まとめ

  • msvcup の導入で、Windowsネイティブ開発の依存地獄から解放
  • ビルド再現性・移植性・クリーンな環境構築 を実現
  • 今後のWindows開発 における新しい標準の一つとして注目

Hackerたちの意見

これ、俺がやってることより難しいわ。まずはLTSCのVisual Studioビルドツールを[1]からインストールして、次にこれをcmdファイルにぶち込むだけ：cl yourprogram.c /link user32.lib advapi32.lib ... みたいな感じで。俺はそれを使って、いろんなユーティリティを作ってる。エディタはvimを使ってるよ。Visual StudioのツールチェーンにはLTSCと安定版があるけど、誰も知らないみたい。詳しくはここを見てね：https://learn.microsoft.com/en-gb/visualstudio/releases/2022... もし一人で開発してるんじゃなくて、他の人と協力しなきゃいけないなら、これを使った方がいいよ。昔みたいに、会社全体でツールチェーンのバージョンを固定してた頃を思い出すね。

└

Visual StudioのツールチェーンにはLTSCと安定版があるけど、誰も知らないみたい。 LTSCチャンネルにアクセスできるのは、少なくともVisual Studio Professionalのライセンスを持ってる場合だけだから（Community版じゃダメ）、多くの趣味プログラマーや学生はこれを知らないんだよね。一方で、仕事でVisual Studioを使ってる人たちの間では、その存在はかなり知られてると思う。

この投稿、AIが書いたの？ 繰り返しのリストや強調されたキーポイント、「ただの[x]じゃなくて[y]」とか「[a]じゃなくて[b]」って表現が、俺にはLLMの匂いがする。どれだけ人間がこの投稿やプロジェクトを作ったのか知りたいな。

└

おそらく、LLMがこのスタイルを広めたから、みんな真似してるんだろうね。読者にとって何かしらのメリットがあるのは確かだし。

└

この投稿はAIが書いたの？もしそうなら？もしそうじゃなかったら？確実にわからないままだったらどうする？すべてのコンテンツについてそんなこと考える？そうだったら、疲れない？

└

もう本当にうんざりだわ。

└

LLMがそんなパターンを繰り返す理由、わかる？それが本物の人間の話し方だからだよ。

└

その識別についてはちょっと迷ってたんだよね。最初の「重要ポイントを強調したリスト」はかなり不自然に感じたし、疑いを持たざるを得なかったよ。全体のリストが、意識的に選んだ人から期待するような一貫性がないし、フォーマットも典型的なものとぴったり合ってるしね。でも、これがLLMのコンテンツなら、LLMはまだ進化してるみたいだね。（AIっぽさはGrammarlyの新機能から来てるのかも。）

  • これはVSの利用規約に違反してないの？ * Microsoftが意図的にこのファーストパーティを提供しないのは、みんなにVSをインストールさせるため、特にプロフェッショナル版やエンタープライズ版を使わせるためかな。最小限のコマンドラインツールと組み合わせると、pyproject.tomlみたいなvsproject.tomlファイルがあって、すべてを自動でやってくれると思うんだけど、なぜかそれは存在しないんだよね。
└

Visual Studioにはその機能があるよ、vsconfigファイルを使ってね：https://learn.microsoft.com/en-us/visualstudio/install/impor...

└

Microsoftは、会社じゃないとあんまり気にしないみたい。それがコミュニティエディションが無料な理由だよ。個人ライセンスは彼らにとってはほんのわずかの利益でしかないし、新しい人が彼らのエコシステムで何かを作ることで、もっと利益を得るからね。彼らにとって、プラットフォームをできるだけアクセスしやすくするのが利益になるんだ。

これは素晴らしいけど、Visual Studioインストーラーには無人インストール用の「コマンドラインパラメータ」があるよ。それを使って、自分の特定の要件やワークロードを分離したスクリプトやドキュメントを作れるんだ：https://learn.microsoft.com/en-us/visualstudio/install/use-c... 2018年にこれをやったことがあるんだけど、クライアントが直接インターネットにアクセスできないDEV/buildマシンで作業してたから（接続があっても、従来の遅い衛星接続だったし）、オフラインインストールパッケージを作るのもプロセスの一部だったんだ。

ビルドエージェントには、必要なビルドツールのバージョンをchocolatey経由でインストールするだけだったよ。でも、いいアプローチだね！

└

同じく。Chocoはこれをワンライナーで解決してくれる。

└

最近はwingetも使えるよ。

Linuxのツールチェインも依存関係地獄からは逃れられないよね。npmパッケージをインストールしたら、裏でcmakeが必要だったことある？glibcの依存関係が解決できなくて、同じビルドで2つの異なるバージョンが必要とか… pythonもまた別の世界だし。あの最新のC++プロジェクト、パッケージマネージャーに入るのが約6ヶ月先のブーストの bleeding edge バージョンが必要とか。Heartbleedの時にopenSSLをパッチ当てたの覚えてる？（libssHELL）。Visual Studioは使いにくいけど、少なくとも一つの犬だからマシ。Windowsの本当の地獄は.NETフレームワークだよ。どのバージョンのWindowsにどのバージョンの.NETフレームワークがインストールされてるか、アプリが起動する時にどのバージョンの.NETで動くかの不一致がすごい… .NETアプリのユニバーサルWindows互換性のための実際の解決策は、事前に.NETをチェックして、複数のバージョンの競合があった場合に正しいバージョンで実行するC++のシムを作ることだよ。実際、同じ.NETターゲットを共有する5つの全く異なるランタイムを持つこともできるからね。

└

POP OS（Ubuntu）からEndeavourOS（Arch）Linuxに移ったんだけど、アプリイメージかなんかのソフトウェアがUbuntuの「最新」のGLIBCで動かなくてイライラしたんだ。もっとモダンなツールを使いたいだけなのに、Archでは今のところ動かないソフトウェアに出会ったことがないよ。もう1年以上経つけどね。

└

これは.NET 5以降で修正されたよ。.NET Frameworkはレガシーアプリケーション用だけに使うべきだね。残念ながら、まだ.NET Frameworkに依存しているアプリがたくさんあるけど。

└

最後に.NETを使ったのはいつ？全然そんなことないよ。.NETランタイムはWindowsにデフォルトで搭載されてて、WU経由で更新されるんだから。ましてや、何年も前から古くなってる.NET Frameworkのことを言ってるんだから。

└

これがCとC++に対してイラッとする点の一つなんだよね、メモリ安全性とは関係なくて：コンパイル/ビルドのUXがすごくストレスフルなんだ。埋め込みに関しては、rust + probe-rsと比べると本当にめちゃくちゃだよ（GPOSなし）。

素晴らしい仕事だね！Visual StudioのDXにとって、長い間待ち望まれていた新鮮な風だよ。大学の時に使わされた時にmsvcupがあったらよかったのに。代わりに、これもあるよ：コンテナにVisual Studio Build Toolsをインストールして、一貫したビルドシステムをサポートする | Microsoft Learn https://learn.microsoft.com/en-us/visualstudio/install/build...

実際、そんなに複雑じゃないよ：global.json [0] でsdkとワークロードのバージョンを指定するだけ。さらに、.csprojファイルでターゲットプラットフォームのsdkバージョンも指定すれば、VSが自動的に開発者に正しいツールチェーンをインストールするように促してくれるよ。[0] https://learn.microsoft.com/en-us/dotnet/core/tools/global-j...

モダンなC#/.NETからwin32インタープロにより、たくさんの「ネイティブ」Windows開発ができるよ。ref戻り値や構造体、スパンなどの新しいC#機能のおかげで、多くの場合オーバーヘッドは検出できないよ。 https://github.com/prasannavl/WinApi https://github.com/microsoft/CsWin32

wineで動くといいな。そうすれば、LinuxからWin64バイナリをクロスコンパイルするのが便利になるし、WindowsのVMを立ち上げる必要もなくなるから。