In che modo Windows gestisce le dipendenze del programma?

23

Ho usato Linux per un bel po 'e mi sono sempre chiesto come Windows fosse in grado di gestire le dipendenze dei programmi come apt-get , aptitude , Pacman , yum e altri gestori di pacchetti sono in grado di fare. A volte, il mio gestore di pacchetti mi diceva che questa versione di quella libreria era necessaria per questo pacchetto o che ci sarebbero stati dei conflitti.

In che modo Windows gestisce tutte queste cose?

windows package-management

— nico
fonte

2

Windows non gestisce le dipendenze della versione. La maggior parte dei programmi di installazione della versione lo fanno. Se non lo conosci già, dai un'occhiata a InnoSetup: jrsoftware.org/isinfo.php

— paulsm4,

4

Probabilmente vale la pena notare che anche nei tuoi esempi, non è Linux in sé a gestire le dipendenze: è il gestore dei pacchetti.

— GalacticCowboy,

3

In che modo Windows gestisce le dipendenze del programma? Male, nella mia esperienza.

— rlms,

29

Non A meno che non stiamo parlando di .NET che ti chiede di installare Framework versione X secondo il compilatore.

Tutto il resto genera solo un errore. Per fortuna, ottieni missing dll xxxx.dll. Tuttavia, la maggior parte dei programmi di installazione includerà le librerie necessarie per eseguire il software.

— Filipe YaBa Polido
fonte

6

Quindi sta al programma di installazione di ciascun programma verificare le dipendenze? Quindi, se il programma di installazione fa schifo, non si può essere in grado di utilizzare il programma a tutti ..

— Nico

Hai dimenticato di dire, no, puoi usare quindi il programma, ma devi capire di quale DLL o framework ha bisogno.

— Filipe YaBa Polido,

9

@Filipe Quindi il fatto che devi installare il runtime V C ++ è il motivo per cui odi il software .NET? Anche Windows per impostazione predefinita ha già installato un framework .NET, quindi se scegli come target la versione giusta funzionerà immediatamente. E il fatto che devi scaricare e installare oggetti condivisi mancanti in realtà non è limitato a nessun particolare software / linguaggio / framework per ovvie ragioni (puoi avere lo stesso "problema" anche in * nix).

— Voo

2

@FilipeYaBaPolido: il tuo odio è particolarmente fuori luogo poiché il runtime di VC ++ 2008 è per applicazioni C ++, non per applicazioni .Net. Ovviamente le applicazioni .Net necessitano del framework .Net e le applicazioni C ++ richiedono il framework C ++ (runtime), in realtà abbastanza semplice. Ora un determinato pacchetto software può contenere parti C ++ e .Net, quindi i due non sono esclusivi.

— Salterio

2

I ragazzi si rilassano, non odio .Net o VC ++. Ho anche codice in .Net / C # quando necessario, è uno strumento. Ma lavoro con alcuni strumenti diversi e vedo le differenze. Scusa se ho spiegato male.

— Filipe YaBa Polido,

40

Modifica 04/04/2014: Ehi OP, guarda cosa è stato appena rilasciato oggi:

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

Volevo solo espandere un po 'la risposta accettata, perché è un po' scarsa nei dettagli. La risposta di Filipe non fa menzione delle strategie effettivamente utilizzate da Windows non fa uso di problemi di risolvere o di dipendenza programma di mitigare, come il negozio componente (WinSxS,) global assembly cache, il sistema MSI, ecc, ma d'altra parte lui è fondamentalmente proprio nel intuire che è responsabilità dello sviluppatore includere eventuali librerie personalizzate con l'app e verificare l'esistenza di dipendenze prima di impegnarsi nella transazione di installazione.

Windows è meno modulare di Linux, che ha aspetti positivi e negativi. Sul lato negativo, Windows è più monolitico, il che significa che relativamente meno componenti del sistema operativo sono rimovibili o opzionali come in Linux. (Anche se Windows sta lentamente migliorando.)

Ma il lato positivo significa che gli sviluppatori sono in grado di fare molte più ipotesi su quali librerie un utente avrà già presente sul proprio computer. E varie versioni di quelle librerie, una volta installate, verranno archiviate fianco a fianco nell'archivio componenti, in modo che non abbiate più App1 che abbaia sulla necessità di crapDLL.dll e App2 che abbaia sulla necessità di una versione diversa di crapDLL.dll allo stesso tempo, ecc.

— Ryan Ries
fonte

Grazie Ryan. So che dovrei elaborare la mia risposta, ma poiché l'inglese non è la mia lingua principale, ho ancora alcune difficoltà ad esprimermi.

— Filipe YaBa Polido,

Ben descritto. Direi, tuttavia, che sta diventando significativamente più modulare sul lato server: opzioni core / senza interfaccia grafica, configurazione basata su ruoli e funzionalità.

— EricB,

Ho letto questo articolo stamattina e mi ha ricordato questo post. È una lettura divertente, sebbene tangenziale, su questo argomento: blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx

— Ryan Ries,

9

In Windows spetta all'autore del software fornire il controllo delle versioni per le loro librerie. Windows ha alcuni servizi per aiutarti.

I servizi di Windows Installer e Trusted Installer che interagiscono con i programmi di installazione (.msi). Esiste anche una tecnologia di supporto denominata Applicazioni isolate e Assiemi affiancati che aiutano a risolvere i conflitti di versione.

Per le applicazioni .NET framework c'è la Global Assembly Cache, gli Strong-Named Assembly e i principali manifesti.

In Windows 8 e 8.1 c'è l'App Store di Windows insieme alla Libreria di Windows Runtime (sostituzione API win32).

modifica: Alla base di gran parte di queste tecnologie ci sono manifesti di assemblaggio, file incorporati che forniscono numeri di versione, autori, assiemi dipendenti e loro versioni, tra gli altri dati.

— Sandwich di pesce rosso
fonte

6

Le altre risposte hanno correttamente sottolineato che la gestione dei pacchetti e il sistema operativo sono idee separate ma non hanno menzionato una soluzione.

Il sistema di gestione dei pacchetti più simile a apt-get o yum su Windows sarebbe attualmente Chocolatey . Consente alle persone di installare / disinstallare pacchetti (msi, exe, script PowerShell) e tali pacchetti possono contenere informazioni sulle loro dipendenze che possono essere automaticamente risolte da Chocolatey.

Il pacchetto di solito contiene un collegamento ai binari e agli script per gestire il processo di installazione. Il pacchetto può contenere anche i file binari o qualsiasi altro file richiesto (le dipendenze devono essere in un pacchetto separato). Chocolatey può anche usare sistemi di gestione dei pacchetti esterni come Microsoft Platform Installer , Ruby Gems, Python e così via.

— AllenSanborn
fonte

Assolutamente! Esistono alcuni gestori di pacchetti di terze parti eseguiti anche su Windows. L'unico che posso nominare in cima alla mia testa è NuGet, è un gestore di pacchetti / dipendenze per gli sviluppatori di applicazioni integrato in Visual Studio. Detto questo, credo che la domanda fosse più alla ricerca di come il sistema operativo gestisce i pacchetti, dove queste soluzioni sono più dirette a come un utente potrebbe gestire i pacchetti.

— Goldfish Sandwich

Spiacenti, non ho incluso alcune informazioni su Chocolatey. Chocolatey è basato su Nuget. Nuget e Nuspec sono solo un pacchetto di "roba" e una specifica delle dipendenze. Nel caso di un framework software come .Net (ruby, node, ...) le dipendenze sono generalmente componenti software (dll, exe, js, ...). Questi sono tutti i componenti utilizzati da un'applicazione.

— AllenSanborn,

Nel caso di Chocolatey, tuttavia, il pacchetto è un'intera applicazione o dipendenza dell'applicazione (framework di app come java, .net, ruby). Il pacchetto Nuget contiene script di PowerShell (facoltativamente anche l'installer) che gestiranno l'installazione dell'app e il file Nuspec descrive l'applicazione e quali dipendenze ha ad esempio Powershell dipende da .Net. C'è anche Boxstarter che si concentra su un livello superiore descrivendo la configurazione di una macchina e da cosa dipende. Roba abbastanza ordinata. Boxstarter entra nel regno di ciò che le persone usano Chef o Puppet.

— AllenSanborn,

0

Da quanto ho capito, le uniche dipendenze gestite da Windows sono le librerie specifiche di Microsoft. Se installi, ad esempio, un programma open source in Windows come Blender, avrà le librerie libavcodec e ffmpeg nei suoi file dll separati e, se installi, dì OpenShot, installerà la propria copia del libavcodec nella propria directory e possono essere versioni completamente diverse. Questo può essere un incubo quando si disinstalla il software per ripulire la posta indesiderata lasciata indietro e occupa anche molto più spazio su disco con ridondanza della libreria.

— Jeff
fonte