Làm thế nào để Windows xử lý các phụ thuộc chương trình?

23

Tôi đã sử dụng Linux khá lâu và tôi luôn tự hỏi làm thế nào Windows có thể xử lý các chương trình phụ thuộc như apt-get , aptitude , Pacman , yum và các trình quản lý gói khác có thể. Đôi khi, người quản lý gói của tôi sẽ nói với tôi rằng phiên bản của thư viện đó là cần thiết cho gói này hoặc sẽ có một số xung đột.

Làm thế nào để Windows xử lý tất cả những thứ đó?

windows package-management

— Nico
nguồn

2

Windows không xử lý các phụ thuộc phiên bản. Hầu hết các trình cài đặt phiên bản làm. Nếu bạn chưa quen với nó, hãy xem InnoSetup: jrsoftware.org/isinfo.php

— paulsm4

4

Có lẽ đáng lưu ý rằng ngay cả trong các ví dụ của bạn, không phải Linux đang quản lý các phụ thuộc - đó là trình quản lý gói.

— GalacticCowboy

3

Làm thế nào để Windows xử lý các phụ thuộc chương trình? Thật tệ, theo kinh nghiệm của tôi.

— rlms

29

Nó không. Trừ khi chúng ta đang nói về .NET yêu cầu bạn cài đặt phiên bản khung X theo trình biên dịch.

Mọi thứ khác chỉ cần ném một lỗi. Với may mắn, bạn có được missing dll xxxx.dll. Mặc dù, hầu hết các trình cài đặt sẽ có các thư viện cần thiết để chạy phần mềm.

— Filipe YaBa Polido
nguồn

6

Vì vậy, nó là tùy thuộc vào trình cài đặt của từng chương trình để kiểm tra các phụ thuộc? Vì vậy, nếu trình cài đặt hút, bạn hoàn toàn không thể sử dụng chương trình ..

— Nico

Quên nói, không, bạn có thể sử dụng sau đó lập trình, nhưng bạn phải tìm ra DLL hoặc khung mà nó cần.

— Filipe YaBa Polido

9

@Filipe Vì vậy, việc bạn phải cài đặt thời gian chạy V C ++ là lý do khiến bạn ghét phần mềm .NET? Ngoài ra, Windows theo mặc định đã cài đặt .NET framework, vì vậy nếu bạn nhắm đúng phiên bản, nó sẽ hoạt động tốt. Và thực tế là bạn phải tải xuống và cài đặt các đối tượng chia sẻ bị thiếu thực sự không giới hạn ở bất kỳ phần mềm / ngôn ngữ / khung cụ thể nào vì những lý do rõ ràng (bạn cũng có thể có "vấn đề" tương tự trong * nix).

— Voo

2

@FilipeYaBaPolido: Sự ghét bỏ của bạn đặc biệt bị đặt nhầm chỗ vì thời gian chạy VC ++ 2008 dành cho các ứng dụng C ++, không phải ứng dụng .Net. Rõ ràng các ứng dụng .Net cần khung .Net và các ứng dụng C ++ cần khung C ++ (thời gian chạy), thực sự khá đơn giản. Bây giờ một gói phần mềm cụ thể có thể chứa cả phần C ++ và .Net để cả hai phần này không độc quyền.

— MSalters

2

Các bạn hãy thư giãn, tôi không ghét .Net hoặc VC ++. Tôi thậm chí còn viết mã bằng .Net / C # khi cần, đó là một công cụ. Nhưng tôi làm việc với một số công cụ khác nhau và thấy sự khác biệt. Xin lỗi nếu tôi giải thích sai.

— Filipe YaBa Polido

40

Chỉnh sửa 4/4/2014: Này OP, hãy nhìn vào những gì vừa được phát hành hôm nay:

http://bloss.technet.com/b/windowsserver/archive/2014/04/03/windows-manloyment-framework-v5-preview.aspx

Tôi chỉ muốn mở rộng một chút về câu trả lời được chấp nhận, bởi vì nó hơi thưa thớt về chi tiết. Câu trả lời Filipe của không đề cập đến trong những chiến lược mà Windows thực sự không sử dụng đến các vấn đề quyết tâm hoặc phụ thuộc chương trình giảm thiểu, như các cửa hàng thành phần (winsxs,) Global Assembly Cache, hệ thống MSI, vv Nhưng mặt khác anh ấy về cơ bản ngay trong cảm nhận rằng trách nhiệm của nhà phát triển là bao gồm bất kỳ thư viện tùy chỉnh nào với ứng dụng và kiểm tra sự tồn tại của các phụ thuộc trước khi thực hiện giao dịch cài đặt.

Windows ít mô-đun hơn Linux, có những mặt tích cực và tiêu cực. Về mặt trái, Windows là nguyên khối hơn, có nghĩa là tương đối ít thành phần của hệ điều hành có thể tháo rời hoặc tùy chọn như trong Linux. (Mặc dù Windows đang dần trở nên tốt hơn về điều đó.)

Nhưng về mặt tích cực, điều đó có nghĩa là các nhà phát triển có thể đưa ra nhiều giả định hơn về những thư viện mà người dùng sẽ có mặt trên máy của họ. Và các phiên bản khác nhau của các thư viện đó, sau khi được cài đặt, sẽ được lưu trữ cạnh nhau trong kho thành phần, do đó bạn không còn bị App1 sủa về việc cần crapDLL.dll và App2 sủa về việc cần một phiên bản khác của crapDLL.dll thời gian, v.v.

— Ryan Ries
nguồn

Cảm ơn Ryan. Tôi biết rằng tôi nên giải thích câu trả lời của mình, nhưng vì tiếng Anh không phải là ngôn ngữ chính của tôi nên tôi vẫn có một số điều khó khăn để thể hiện bản thân.

— Filipe YaBa Polido

Cũng được mô tả. Tuy nhiên, tôi sẽ nói rằng nó sẽ trở nên nhiều mô-đun hơn đáng kể ở phía máy chủ - các tùy chọn cốt lõi / không có gui, thiết lập dựa trên vai trò và tính năng.

— EricB

Tôi đọc bài viết này sáng nay và nó nhắc tôi về bài viết này. Đây là một trò giải trí, mặc dù tiếp tuyến đọc về chủ đề này: blog.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx

— Ryan Ries

9

Trong Windows, tác giả phần mềm phải cung cấp phiên bản cho thư viện của họ. Windows có một vài phương tiện để trợ giúp việc này.

Trình cài đặt Windows và các dịch vụ Trình cài đặt đáng tin cậy tương tác với các chương trình cài đặt (.msi). Ngoài ra còn có một số công nghệ hỗ trợ được gọi là Ứng dụng biệt lập và Lắp ráp song song giúp loại bỏ xung đột phiên bản.

Đối với các ứng dụng .NET framework có Bộ đệm ẩn hội đồng toàn cầu, Bộ lắp ráp được đặt tên mạnh và ở Bản kê khai cốt lõi.

Trong Windows 8 và 8.1 có Windows App Store cùng với Windows Runtime Library (thay thế API win32).

chỉnh sửa: Cốt lõi của hầu hết các công nghệ này là các bảng kê khai lắp ráp, các tệp nhúng cung cấp số phiên bản, tác giả, tập hợp phụ thuộc và phiên bản của chúng, cùng với các dữ liệu khác.

— Sandwich cá vàng
nguồn

6

Các câu trả lời khác đã chỉ ra một cách chính xác rằng quản lý gói và HĐH là những ý tưởng riêng biệt nhưng không đề cập đến một giải pháp.

Hệ thống quản lý gói tương tự nhất với apt-get hoặc yum trên Windows hiện tại sẽ là Chocolatey . Nó cho phép mọi người cài đặt / gỡ cài đặt các gói (msi, exe, powershell script) và những gói đó có thể chứa thông tin về các phụ thuộc của chúng có thể được giải quyết tự động bởi Chocolatey.

Gói thường chứa một liên kết đến các tệp nhị phân và tập lệnh để quản lý quá trình cài đặt. Gói này cũng có thể chứa các tệp nhị phân hoặc bất kỳ tệp nào được yêu cầu (phụ thuộc phải nằm trong một gói riêng). Chocolatey cũng có thể sử dụng các hệ thống quản lý gói bên ngoài như Trình cài đặt nền tảng web của Microsoft , Ruby Gems, Python, v.v.

— AllenSanborn
nguồn

Chắc chắn rồi! Có một số nhà quản lý gói bên thứ ba cũng chạy trên Windows. Người duy nhất tôi có thể đặt tên trên đỉnh đầu là NuGet, trình quản lý gói / phụ thuộc dành cho các nhà phát triển ứng dụng được tích hợp ngay trong Visual Studio. Điều đó nói rằng tôi tin rằng câu hỏi là tìm kiếm nhiều hơn về cách hệ điều hành xử lý các gói, trong đó các giải pháp này hướng nhiều hơn đến cách người dùng có thể xử lý các gói.

— Sandwich cá vàng

Xin lỗi tôi đã không bao gồm một số thông tin về Chocolatey. Chocolatey được dựa trên Nuget. Nuget và Nuspec chỉ là một gói 'công cụ' và là một đặc điểm của sự phụ thuộc. Trong trường hợp khung công tác phần mềm như .Net (ruby, nút, ...), các phụ thuộc thường là các thành phần phần mềm (dll, exe, js, ...). Đó là tất cả các thành phần mà một ứng dụng sử dụng.

— AllenSanborn

Trong trường hợp của Chocolate, mặc dù gói là toàn bộ ứng dụng hoặc phụ thuộc ứng dụng (khung ứng dụng như java, .net, ruby). Gói Nuget chứa các tập lệnh PowerShell (tùy chọn trình cài đặt) cũng sẽ quản lý việc cài đặt ứng dụng và tệp Nuspec mô tả ứng dụng và phụ thuộc của nó, ví dụ như Powershell phụ thuộc vào .Net. Ngoài ra còn có Boxstarter tập trung mức cao hơn bằng cách mô tả cấu hình của máy và những gì nó phụ thuộc vào. Thứ khá gọn gàng. Boxstarter đi vào vương quốc của những gì mọi người sử dụng Chef hoặc Puppet cho.

— AllenSanborn

0

Theo những gì tôi hiểu, các phụ thuộc duy nhất được xử lý bởi Windows là các thư viện cụ thể của Microsoft. Nếu bạn cài đặt, ví dụ, một chương trình nguồn mở trong Windows như Blender, nó sẽ có các thư viện libavcodec và ffmpeg trong các tệp dll riêng của nó và nếu sau đó bạn cài đặt, nói, OpenShot, nó sẽ cài đặt bản sao của chính nó libavcodec trong thư mục riêng của mình và chúng có thể là các phiên bản hoàn toàn khác nhau. Đây có thể là một cơn ác mộng khi gỡ cài đặt phần mềm để dọn sạch rác còn sót lại và nó cũng chiếm nhiều không gian đĩa hơn với sự dư thừa của thư viện.

— Jeff
nguồn