Bagaimana Windows menangani dependensi program?

23

Saya telah menggunakan Linux selama beberapa waktu, dan saya selalu bertanya-tanya bagaimana Windows dapat menangani program-program ketergantungan seperti apt-get , aptitude , Pacman , yum dan manajer paket lainnya. Kadang-kadang, manajer paket saya akan memberi tahu saya bahwa versi perpustakaan itu diperlukan untuk paket ini atau bahwa akan ada beberapa konflik.

Bagaimana Windows menangani semua hal itu?

windows package-management

— Nico
sumber

2

Windows tidak menangani dependensi versi. Kebanyakan versi installer melakukannya. Jika Anda belum terbiasa dengan hal itu, periksa InnoSetup: jrsoftware.org/isinfo.php

— paulsm4

4

Mungkin perlu dicatat bahwa bahkan dalam contoh Anda, bukan Linux yang mengelola dependensi - melainkan manajer paket.

— GalacticCowboy

3

Bagaimana Windows menangani dependensi program? Buruk, dalam pengalaman saya.

— rlms

29

Tidak. Kecuali jika kita berbicara tentang .NET yang meminta Anda untuk menginstal kerangka kerja versi X sesuai dengan kompiler.

Yang lainnya hanya melempar kesalahan. Dengan keberuntungan, Anda dapat missing dll xxxx.dll. Meskipun, sebagian besar penginstal akan memiliki perpustakaan yang diperlukan untuk menjalankan perangkat lunak.

— Filipe YaBa Polido
sumber

6

Jadi terserah installer dari masing-masing program untuk memeriksa ketergantungannya? Jadi jika penginstalnya payah, Anda mungkin tidak dapat menggunakan program sama sekali ..

— Nico

Lupa mengatakan, tidak, Anda dapat menggunakan program itu, tetapi Anda harus mencari tahu DLL atau kerangka kerja yang dibutuhkan.

— Filipe YaBa Polido

9

@Filipe Jadi fakta bahwa Anda harus menginstal runtime V C ++ adalah alasan mengapa Anda membenci perangkat lunak .NET? Juga Windows secara default sudah memiliki .NET framework yang diinstal, jadi jika Anda menargetkan versi yang tepat itu akan bekerja di luar kotak. Dan fakta bahwa Anda harus mengunduh dan menginstal objek bersama yang hilang benar-benar tidak terbatas pada perangkat lunak / bahasa / kerangka kerja tertentu untuk alasan yang jelas (Anda dapat memiliki "masalah" yang sama di * nix juga).

— Voo

2

@FilipeYaBaPolido: Kebencian Anda khususnya salah tempat karena runtime VC ++ 2008 untuk aplikasi C ++, bukan aplikasi .Net. Jelas aplikasi .Net membutuhkan framework .Net dan aplikasi C ++ membutuhkan framework C ++ (runtime), sebenarnya cukup sederhana. Sekarang paket perangkat lunak tertentu dapat berisi bagian-bagian C ++ dan .Net sehingga keduanya tidak eksklusif.

— MSalters

2

Teman-teman santai, saya tidak benci. Net atau VC ++. Saya bahkan kode dalam. Net / C # ketika diperlukan, ini adalah alat. Tetapi saya bekerja dengan beberapa alat yang berbeda dan melihat perbedaannya. Maaf kalau saya jelaskan salah.

— Filipe YaBa Polido

40

Sunting 4/4/2014: Hai OP, lihat apa yang baru dirilis hari ini:

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

Saya hanya ingin memperluas sedikit pada jawaban yang diterima, karena itu sedikit detail. Jawaban Filipe ini tidak menyebutkan strategi yang Windows benar-benar tidak digunakan untuk menyelesaikan atau ketergantungan Program mengurangi masalah, seperti toko komponen (WinSxS,) cache perakitan global, sistem MSI, dll Tapi di sisi lain dia pada dasarnya tepat di merasakan bahwa itu tanggung jawab pengembang untuk memasukkan perpustakaan khusus apa pun dengan aplikasi, dan memeriksa keberadaan dependensi sebelum melakukan transaksi instal.

Windows kurang modular daripada Linux, yang memiliki positif dan negatif. Di sisi bawah, Windows lebih monolitik, artinya komponen yang relatif lebih sedikit dari sistem operasi dapat dilepas atau opsional seperti di Linux. (Meskipun Windows perlahan mulai membaik tentang hal itu.)

Tetapi di sisi atas, itu berarti pengembang dapat membuat lebih banyak asumsi tentang perpustakaan apa yang sudah ada pengguna di komputernya. Dan berbagai versi dari pustaka tersebut, setelah diinstal, akan disimpan berdampingan di toko komponen, sehingga Anda tidak lagi memiliki App1 menggonggong tentang membutuhkan crapDLL.dll, dan App2 menggonggong tentang membutuhkan versi lain dari crapDLL.dll pada saat yang sama. waktu, dll.

— Ryan Ries
sumber

Terima kasih Ryan. Saya tahu bahwa saya harus menguraikan jawaban saya, tetapi karena bahasa Inggris bukan bahasa utama saya, saya masih memiliki beberapa kesulitan untuk mengekspresikan diri.

— Filipe YaBa Polido

Dijelaskan dengan baik. Saya akan, bagaimanapun, mengatakan itu menjadi lebih modular secara signifikan di sisi server - opsi inti / bebas gui, peran dan pengaturan berbasis fitur.

— EricB

Saya membaca artikel ini pagi ini dan mengingatkan saya pada posting ini. Ini adalah bacaan yang menghibur, meskipun tangensial membaca tentang topik ini: blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx

— Ryan Ries

9

Di Windows, tergantung pada pembuat perangkat lunak untuk menyediakan versi untuk pustaka mereka. Windows memiliki beberapa fasilitas untuk membantu ini.

Pemasang Windows dan layanan Pemasang Tepercaya yang berinteraksi dengan program instalasi (.msi). Ada juga beberapa teknologi pendukung yang disebut Aplikasi Terisolasi dan Perakitan Berdampingan yang membantu memilah konflik versi.

Untuk aplikasi .NET framework ada Global Assembly Cache, Strong-Named Assemblies, dan pada Manifest inti.

Di Windows 8 dan 8.1 ada Windows App Store bersama dengan Windows Runtime Library (pengganti win32 API).

sunting: Inti dari sebagian besar teknologi ini adalah manifes rakitan, file yang disematkan yang menyediakan nomor versi, penulis, rakitan bergantung, dan versinya, di antara data lainnya.

— Sandwich Ikan Mas
sumber

6

Jawaban lain benar menunjukkan bahwa manajemen paket dan OS adalah ide yang terpisah tetapi tidak menyebutkan solusi.

Sistem manajemen paket yang paling mirip dengan apt-get atau yum di Windows saat ini adalah Chocolatey . Ini memungkinkan orang untuk menginstal / menghapus paket (MSI, exe, skrip PowerShell,) dan paket tersebut dapat berisi informasi tentang dependensi mereka yang dapat secara otomatis diselesaikan oleh Chocolatey.

Paket ini biasanya berisi tautan ke binari dan skrip untuk mengelola proses pemasangan. Paket ini juga dapat berisi binari atau file lain yang diperlukan (dependensi harus dalam paket terpisah). Chocolatey juga dapat menggunakan sistem manajemen paket eksternal seperti Penginstal Platform Web Microsoft , Ruby Gems, Python, dan sebagainya.

— AllenSanborn
sumber

Benar! Ada beberapa manajer paket pihak ketiga yang juga berjalan di Windows. Satu-satunya yang saya dapat nama dari atas kepala saya adalah NuGet, itu adalah manajer paket / dependensi untuk pengembang aplikasi yang dibangun langsung ke Visual Studio. Yang mengatakan saya percaya pertanyaannya lebih mencari bagaimana sistem operasi menangani paket, di mana solusi ini lebih ke arah bagaimana pengguna dapat menangani paket.

— Goldfish Sandwich

Maaf saya tidak memasukkan beberapa informasi tentang Chocolatey. Chocolatey didasarkan dari Nuget. Nuget dan Nuspec hanyalah paket 'barang' dan spesifikasi dependensi. Dalam kasus kerangka kerja perangkat lunak seperti. Net (ruby, node, ...) dependensi biasanya komponen perangkat lunak (dll, exe, js, ...). Itu semua adalah komponen yang digunakan aplikasi.

— AllenSanborn

Dalam kasus Chocolatey, meskipun paket adalah seluruh aplikasi atau ketergantungan aplikasi (kerangka kerja aplikasi seperti java, .net, ruby). Paket Nuget berisi skrip PowerShell (opsional juga installer) yang akan mengelola instalasi aplikasi dan file Nuspec menjelaskan aplikasi dan dependensi apa yang dimilikinya misalnya Powershell bergantung pada .Net. Ada juga Boxstarter yang memfokuskan tingkat yang lebih tinggi dengan menggambarkan konfigurasi mesin dan tergantung pada apa. Cukup rapi. Boxstarter masuk ke ranah untuk apa orang menggunakan Chef atau Wayang.

— AllenSanborn

0

Dari apa yang saya mengerti, satu-satunya dependensi yang ditangani oleh Windows adalah perpustakaan khusus Microsoft. Jika Anda menginstal, sebagai contoh, program open source di Windows seperti Blender, ia akan memiliki libavcodec dan pustaka ffmpeg dalam file dll yang terpisah, dan jika Anda menginstal katakanlah, OpenShot, ia akan menginstal salinannya sendiri dari libavcodec di direktori sendiri, dan mereka dapat menjadi versi yang sama sekali berbeda. Ini bisa menjadi mimpi buruk ketika menghapus instalan perangkat lunak untuk membersihkan sampah yang tertinggal, dan juga membutuhkan ruang disk lebih banyak dengan redundansi perpustakaan.

— Jeff
sumber