Tôi đã sửa môi trường phát triển native trên Windows

 (marler8997.github.io)
8 điểm bởi GN⁺ 2026-02-16 | 5 bình luận | Chia sẻ qua WhatsApp
  • Việc phát triển native trên Windows trở nên phức tạp và kém hiệu quả do phụ thuộc vào cài đặt Visual Studio
  • Dung lượng cài đặt lên tới hàng chục GB, quản lý thành phần thiếu minh bạch, vấn đề lệch phiên bản cùng nhiều yếu tố khác làm giảm năng suất của lập trình viên
  • Để giải quyết điều này, một công cụ CLI nhẹ tênh là msvcup đã được phát triển, cho phép tự động cài đặt toolchain MSVC và Windows SDK theo từng phiên bản và trong môi trường cách ly
  • msvcup cung cấp môi trường build có thể tái lập thông qua phân tích JSON manifest, thiết lập môi trường tự động (autoenv), hỗ trợ lock file và nhiều tính năng khác
  • Cách tiếp cận này không phụ thuộc vào Visual Studio Installer, đồng thời cho phép xây dựng hệ thống build tự động hoàn toàn dựa trên script

Vấn đề của phát triển native trên Windows

  • Cách làm truyền thống buộc phải cài Visual Studio tạo gánh nặng cho lập trình viên do quy trình cài đặt phức tạp và quản lý dependency thiếu ổn định
    • Cần chọn chi tiết như workload “Desktop development with C++”, phiên bản SDK cụ thể..., và nếu chọn sai thì build có thể thất bại
    • Dung lượng cài đặt có thể đạt 50GB, và ngay cả sau khi gỡ bỏ vẫn còn lại mục registry dư thừa và các dịch vụ chạy nền
  • Trên Linux, chỉ cần một lệnh package manager là có thể cài toolchain, nhưng trên Windows người dùng phải chọn thủ công hàng nghìn thành phần
  • Visual Studio là một cấu trúc nguyên khối nơi editor, compiler và SDK gắn chặt với nhau, khiến việc quản lý phiên bản và tái tạo môi trường trở nên khó khăn
  • Kết quả là tình trạng kiểu “máy tôi thì chạy” xảy ra thường xuyên, và đây trở thành rào cản gia nhập đối với phát triển native

msvcup: cách tiếp cận mới

  • msvcup là công cụ CLI mã nguồn mở cho phép tải xuống và cài đặt trực tiếp toolchain MSVC cùng Windows SDK mà không cần cài Visual Studio
    • Mỗi phiên bản được cài vào thư mục cách ly bên dưới C:\msvcup\, nên có thể dùng song song mà không xảy ra xung đột giữa các phiên bản
    • Việc cài đặt hoàn tất chỉ trong vài phút, đồng thời tự động bao gồm cả công cụ cross-compile cho ARM
  • Lệnh msvcup install cài các gói cần thiết, còn lệnh autoenv tạo ra thư mục môi trường tự động
    • Thư mục này chứa các tệp thực thi wrapper để tự động thiết lập biến môi trường và tệp toolchain.cmake, nhờ đó các dự án CMake cũng có thể build mà không cần cấu hình riêng
  • Trong ví dụ script build.bat, chương trình “Hello, World” có thể được build không cần Visual Studio thông qua msvcup
    • Chỉ cần có curl và tar trên Windows 10 trở lên là có thể hoạt động

Cơ chế hoạt động bên trong

  • Công cụ này phân tích JSON manifest của các thành phần Visual Studio do Microsoft phát hành để xác định chính xác những gói cần thiết
    • Chỉ các thành phần cốt lõi như compiler, linker, header và library mới được tải trực tiếp từ Microsoft CDN
  • Các thành phần đã cài được quản lý bằng lock file, cho phép cả nhóm dùng chung cùng một phiên bản gói
  • Các lệnh install và autoenv có tính idempotent, nên nếu đã được cài từ trước thì chúng sẽ hoàn tất chỉ trong vài mili giây

Trường hợp áp dụng thực tế

  • Tuple (ứng dụng pair programming) đã tích hợp msvcup vào hệ thống build CI để loại bỏ yêu cầu phải cài sẵn Visual Studio
    • Có thể build hàng trăm dự án C/C++, bao gồm cả WebRTC, bằng cùng một toolchain/SDK
    • Hỗ trợ cả build x86_64 lẫn ARM
  • Ưu điểm
    • Cài đặt theo thư mục riêng cho từng phiên bản giúp quản lý nhiều phiên bản song song và cài lại dễ dàng
    • Tự động hỗ trợ cross-compile, không cần cấu hình riêng
    • Bảo đảm tính tái lập dựa trên lock file, đồng thời có thể phát hiện ngay khi phía Microsoft thay đổi
    • Tốc độ thực thi nhanh, không có cài đặt lại không cần thiết

Giới hạn và mở rộng

  • msvcup được thiết kế tập trung vào toolchain biên dịch, nên nếu cần chính IDE Visual Studio thì vẫn phải dùng cách cài chính thức
  • Tuy vậy, trong hầu hết các quy trình phát triển native, nó vẫn cung cấp môi trường build hoàn chỉnh mà không cần IDE
  • Ví dụ script build raylib cho thấy có thể tự động cài SDK và toolchain rồi build dự án mà không cần Visual Studio
    • Toàn bộ quy trình build tự động được thực hiện chỉ bằng dòng lệnh, không cần GUI

Kết luận

  • msvcup loại bỏ sự phức tạp của Visual Studio Installer và cung cấp môi trường build native nhẹ, có thể quản lý theo phiên bản
  • Cách tiếp cận này chuyển đổi việc phát triển native trên Windows sang mô hình có thể tái lập và tự động hóa, giúp lập trình viên thoát khỏi sự phụ thuộc vào IDE
  • Repo : https://github.com/marler8997/msvcup

Bài viết liên quan

5 bình luận

 
GN⁺ 2026-02-16
Ý kiến trên Hacker News

  • Việc này trông còn phức tạp hơn những gì tôi làm
    Chỉ cần cài LTSC Visual Studio Build Tools, rồi đưa lệnh như cl yourprogram.c /link user32.lib advapi32.lib ... vào một file cmd là được
    Tôi chỉnh sửa bằng vim và đã build nhiều tiện ích theo cách này
    Trong toolchain Visual Studio có cả LTSC và bản ổn định, nhưng đa số không biết điều đó
    Nếu là môi trường cộng tác, tốt hơn nên dùng bản cố định trong tài liệu lịch sử phát hành chính thức
    Kiểu như thời trước khi cả công ty cùng cố định dùng một phiên bản toolchain giống nhau

    • Kênh LTSC chỉ có thể truy cập nếu có giấy phép Visual Studio Professional trở lên
      Vì vậy sinh viên hay lập trình viên hobby thường không biết
      Ngược lại, những người dùng VS trong công ty thì đa số đều biết
    • Visual Studio 2026 vẫn chưa có bản phát hành LTSC
      Có ai biết khi nào nó sẽ ra không?

  • Toolchain trên Linux cũng không hề miễn nhiễm với địa ngục phụ thuộc
    Cài package npm rồi lại cần cmake, hoặc bị xung đột phiên bản glibc, hoặc gặp dự án C++ đòi boost mới nhất...
    Tôi vẫn còn nhớ thời vá openSSL khi xảy ra heartbleed
    Visual Studio đúng là bất tiện, nhưng địa ngục thực sự là sự hỗn loạn phiên bản .NET Framework
    Mỗi phiên bản Windows lại cài sẵn .NET khác nhau, và cũng không rõ app sẽ chạy trên runtime nào
    Vì thế khi triển khai quy mô lớn, phải viết shim kiểm tra phiên bản .NET bằng C++ để bảo đảm nó chạy trên đúng runtime

    • Nếu ngay cả glibc tự nó cũng gây ra vấn đề phụ thuộc thì đúng là hiếm đến mức tôi muốn nghe thử
      Nhóm glibc rất nghiêm ngặt về tương thích ngược và tương thích xuôi
      Bài LWN có nhắc lần gần nhất họ phá vỡ tính tương thích là khi nào
      Vấn đề là mọi người thường pin sai phiên bản glibc
      glibc không nên bị pin phiên bản
      GCC có vài lần phá tương thích, nhưng đa phần là do thay đổi trong chuẩn C++
    • .NET gần đây đã hoàn toàn khác rồi
      .NET Framework giờ đã là legacy, và từ .NET 5 trở đi thì không còn vấn đề này nữa
      Chỉ là vẫn còn rất nhiều ứng dụng phụ thuộc vào bản cũ
    • Trước đây trong phát triển C/C++, chỉ package manager của hệ thống là đã đủ, nhưng do vấn đề phiên bản mới nên mới xuất hiện package manager theo từng ngôn ngữ
      Chúng giải quyết được vấn đề, nhưng đồng thời cũng tạo ra độ phức tạp mới
      Đôi khi tôi chỉ muốn quay lại thời package manager hệ thống là đủ
    • Ma sát UX khi build trong C/C++ là thứ gây khó chịu, tách biệt hẳn với vấn đề an toàn bộ nhớ
      Ở môi trường embedded thì phía rust + probe-rs dễ chịu hơn nhiều

  • Trình cài đặt Visual Studio hỗ trợ cài đặt không giám sát bằng tham số dòng lệnh
    Điều này được giải thích trong tài liệu chính thức
    Năm 2018, khi tôi làm việc trong môi trường mạng vệ tinh internet chậm, tôi đã dùng cách này vì cần tạo gói cài đặt offline

    • Tôi đã thử, nhưng có quá nhiều tải xuống không cần thiết, và việc cài đặt vẫn yêu cầu quyền quản trị viên
    • (Kết nối độ trễ cao nhỉ... có lẽ diễn đạt “high-latency” sẽ đúng hơn)

  • Nhìn vào script thì thấy
    curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
    kiểu như vậy
    Nhưng tôi ngại cài file thực thi từ một tài khoản GitHub không rõ nguồn gốc mà không xác minh hash
    Tình hình trên Windows không tệ đến mức như bài blog nói, nhưng đây có vẻ không phải giải pháp mà chỉ là một script cài đặt rủi ro khác

    • Không nhất thiết phải cài file thực thi
      Chỉ cần đọc và rà soát trực tiếp script là được
      Cách curl|sh rốt cuộc cũng chỉ là tải mã nguồn về, chứ không nguy hiểm hơn việc cài thẳng file thực thi
    • Jonathan Marler nổi tiếng nhờ các bài nói về Zig và công việc binding win32 API
      Dự án zigwin32 của anh ấy còn được liên kết từ win32metadata của Microsoft
      Tức là đây là một người đáng tin cậy

  • Bài này tạo cảm giác như được AI viết
    Cấu trúc câu kiểu “it’s not just X, but Y” hay các danh sách nhấn mạnh là phong cách LLM rất điển hình
    Tôi tò mò không biết dự án này do con người làm đến mức nào

    • Nick của bạn là “its_notjack” nên cũng hơi buồn cười
    • Lúc đầu tôi cũng nghi ngờ
      Cấu trúc danh sách hơi kỳ và thiếu nhất quán
      Nhưng nếu đúng là do LLM viết thì có lẽ đó cũng là bằng chứng cho thấy chất lượng LLM dạo này đã tăng khá nhiều
      Cũng có thể là ảnh hưởng của các công cụ như Grammarly
    • Có khi mọi người đang bắt chước phong cách LLM
      Vì người đọc thấy nó dễ theo dõi hơn
    • Những cách diễn đạt như “The key insight is...” là văn phong Claude hay dùng, nên mới tạo cảm giác đó
      Thành thật mà nói, tôi chỉ mong họ công khai việc có dùng AI hay không

  • Trong nỗ lực cải thiện DX của Visual Studio, msvcup thực sự khá mới mẻ
    Hồi còn học đại học, tôi đã ước có thứ như thế này
    Một lựa chọn khác là cài Build Tools trong container

  • Cứ cài bằng winget là được
    winget install --id Microsoft.VisualStudio.2022.BuildTools
    Nếu cần tính năng WinRT thì có thể thêm
    winget install --id Microsoft.WindowsSDK.10.0.18362
    winget install --id Microsoft.WindowsAppRuntime.1.8

    • Trước đây tôi từng hỗ trợ các package này, và nó không hề đơn giản
      Bạn còn phải chỉ định cài workload nào, và nếu không biết dự án cần gì thì sẽ phải mò mẫm khá nhiều
      .vsconfig có giúp đôi chút nhưng không hoàn hảo

  • Tôi mong các dự án mã nguồn mở đừng chặn hỗ trợ MinGW
    Đây là một compiler tốt, hoạt động ổn mà không cần thêm DLL
    Tôi không hiểu vì sao mã nguồn mở lại phải ép dùng compiler độc quyền

    • MinGW không tương thích với một số thư viện chỉ dành cho Windows (WIL)
      WIL là thư viện mà các lập trình viên kernel rất thích dùng, vì nó cải thiện đáng kể độ an toàn và tính tiện dụng của code
    • Khi cần liên kết với thư viện MSVC được build từ bên ngoài thì MinGW không phải lựa chọn khả thi
      Ví dụ Steamworks SDK build được bằng MinGW nhưng sẽ crash khi chạy runtime
    • Tôi cũng mong có nhiều hỗ trợ MinGW hơn
      Đáng tiếc là bài blog này còn không nhắc tới nó
    • Tôi không thích MinGW
      Kết hợp Clang + MSVC STL + WinSDK đơn giản là gọn gàng hơn nhiều

  • Hoặc cũng có thể làm đơn giản như sau
    "winget install Microsoft.VisualStudio.BuildTools"
    "winget install Microsoft.WindowsSDK.10.0.26100"

    • Tôi cũng luôn làm như vậy
      Tôi thích nó vì độ ổn định so với công sức bỏ ra là rất tốt
    • Nhưng kiểu cài này là trên toàn hệ thống, nên sẽ bất tiện nếu mỗi dự án cần một phiên bản khác nhau
      Giá mà mọi ngôn ngữ đều có công cụ cô lập phiên bản như Python uv
    • Phần lớn những lời chỉ trích Windows là câu chuyện của 20 năm trước
      Những thứ như Bing, Copilot hay quảng cáo thì đúng là đáng chê, nhưng phần lớn đều có thể tắt đi
 
click 2026-02-16

Tôi cũng build trên Ubuntu 24.04 rồi định chạy trên CentOS 6 hay 7 gì đó thì gặp vấn đề phụ thuộc glibc.
Có vẻ vấn đề là mặc định sẽ lấy phiên bản glibc của môi trường build.
 
penza1 2026-02-18

Không còn cách nào khác ngoài việc phụ thuộc vào glibc..
Nếu không phải là ngôn ngữ script như Python/JVM/.NET/JS thì việc phụ thuộc vào glibc là điều khó tránh khỏi.
Đó cũng là lý do phải phân phối thư viện theo từng bản phân phối.
Ít nhất thì những gì được build trên glibc, nếu không có phụ thuộc đặc biệt nào khác, vẫn hoàn toàn có thể chạy trên các bản phân phối phiên bản cao hơn.
 
geekbini 2026-02-16

WSL2 với Ubuntu đúng là đã khiến việc phát triển trên Windows tốt hơn nhiều. Tuy nhiên, nếu là môi trường Visual Studio chứ không phải VS Code thì có vẻ cái này vẫn sẽ phần nào hữu ích. Mà có vẻ việc này không làm được trực tiếp trên Windows bằng các trình quản lý gói như choco hay winget nhỉ.
 
click 2026-02-16

Có vẻ như các package manager thường tập trung vào thành phẩm cuối cùng hơn là SDK.
Những thứ như vcredist thì đa số lập trình viên thường cấu hình để cài đặt ngay trong script của package manager.
Còn môi trường build thì đúng là hơi khác một chút.