¿Cómo maneja Windows las dependencias del programa?

23

He usado Linux durante bastante tiempo, y siempre me he preguntado cómo Windows pudo manejar las dependencias de los programas como apt-get , aptitude , Pacman , yum y otros administradores de paquetes. A veces, mi administrador de paquetes me decía que esta versión de esa biblioteca era necesaria para este paquete o que habría algún conflicto.

¿Cómo maneja Windows todas esas cosas?

windows package-management

— Nico
fuente

2

Windows no maneja las dependencias de la versión. La mayoría de los instaladores de versiones lo hacen. Si aún no lo conoce, consulte InnoSetup: jrsoftware.org/isinfo.php

— paulsm4 el

44

Probablemente valga la pena señalar que incluso en sus ejemplos, no es Linux per se el que administra las dependencias, es el administrador de paquetes.

— GalacticCowboy

3

¿Cómo maneja Windows las dependencias del programa? Mal, en mi experiencia.

— rlms

29

No lo hace. A menos que estemos hablando de .NET que le pide que instale la versión X de framework de acuerdo con el compilador.

Todo lo demás solo arroja un error. Con suerte, lo tienes missing dll xxxx.dll. Aunque, la mayoría de los instaladores tendrán incluidas las bibliotecas necesarias para ejecutar el software.

— Filipe YaBa Polido
fuente

66

Entonces, ¿depende del instalador de cada programa verificar las dependencias? Entonces, si el instalador apesta, es posible que no pueda usar el programa en absoluto ...

— Nico

Olvidé decir que no, puede usar el programa, pero tiene que averiguar qué DLL o marco necesita.

— Filipe YaBa Polido

99

@Filipe ¿Entonces el hecho de que tenga que instalar el tiempo de ejecución de V C ++ es la razón por la que odia el software .NET? Además, Windows de manera predeterminada ya tiene un marco .NET instalado, por lo que si apunta a la versión correcta, funcionará de inmediato. Y el hecho de que tenga que descargar e instalar objetos compartidos que faltan realmente no se limita a ningún software / lenguaje / marco particular por razones obvias (también puede tener el mismo "problema" en * nix).

— Voo

2

@FilipeYaBaPolido: Su odio está particularmente fuera de lugar ya que el tiempo de ejecución de VC ++ 2008 es para aplicaciones C ++, no para aplicaciones .Net. Obviamente, las aplicaciones .Net necesitan el marco .Net y las aplicaciones C ++ necesitan el marco C ++ (tiempo de ejecución), bastante simple en realidad. Ahora, un paquete de software en particular puede contener partes C ++ y .Net, por lo que las dos no son exclusivas.

— MSalters

2

Chicos, relájate, no odio .Net o VC ++. Incluso codifico en .Net / C # cuando es necesario, es una herramienta. Pero trabajo con algunas herramientas diferentes y veo las diferencias. Lo siento si te expliqué mal.

— Filipe YaBa Polido

40

Edición 4/4/2014: Hola OP, mira lo que se acaba de lanzar hoy:

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

Solo quería ampliar un poco la respuesta aceptada, porque es un poco escasa en detalles. La respuesta de Filipe no hace mención de las estrategias que Windows realidad hace uso de las cuestiones a resolver o dependencia programa de mitigar, al igual que el almacén de componentes (WinSxS,) la caché de ensamblados global, el sistema MSI, etc, pero por otro lado que es básicamente justo en el tiene la sensación de que es responsabilidad del desarrollador incluir bibliotecas personalizadas con la aplicación y verificar la existencia de dependencias antes de comprometerse con la transacción de instalación.

Windows es menos modular que Linux, que tiene aspectos positivos y negativos. En el lado negativo, Windows es más monolítico, lo que significa que relativamente menos componentes del sistema operativo son extraíbles u opcionales como en Linux. (Aunque Windows está mejorando lentamente al respecto).

Pero en el lado positivo, eso significa que los desarrolladores pueden hacer muchas más suposiciones sobre las bibliotecas que un usuario ya tendrá presentes en su máquina. Y varias versiones de esas bibliotecas, una vez instaladas, se almacenarán una al lado de la otra en el almacén de componentes, de modo que ya no tenga App1 ladrando sobre la necesidad de crapDLL.dll, y App2 ladrando sobre la necesidad de una versión diferente de crapDLL.dll al mismo tiempo. tiempo, etc.

— Ryan Ries
fuente

Gracias Ryan Sé que debo elaborar mi respuesta, pero como el inglés no es mi idioma principal, todavía tengo algunas dificultades para expresarme.

— Filipe YaBa Polido

Bien descrito. Sin embargo, diría que se está volviendo significativamente más modular en el lado del servidor: opciones sin núcleo / gui, configuración basada en funciones y funciones.

— EricB

Leí este artículo esta mañana y me recordó esta publicación. Es una lectura entretenida, aunque tangencial sobre este tema: blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx

— Ryan Ries

9

En Windows, corresponde al autor del software proporcionar versiones de sus bibliotecas. Windows tiene algunas facilidades para ayudar con esto.

Windows Installer y los servicios Trusted Installer que interactúan con los programas de instalación (.msi). También hay una tecnología de soporte llamada Aplicaciones Aisladas y Ensamblados uno al lado del otro que ayudan a resolver conflictos de versiones.

Para las aplicaciones de .NET framework existe la Caché de ensamblados global, los ensamblados con nombres sólidos y los Manifiestos principales.

En Windows 8 y 8.1 existe la Tienda de aplicaciones de Windows junto con la Biblioteca de tiempo de ejecución de Windows (reemplazo de la API win32).

editar: El núcleo de la mayoría de estas tecnologías son los manifiestos de ensamblaje, los archivos incrustados que proporcionan números de versión, los autores, los ensamblajes dependientes y sus versiones, entre otros datos.

— Sandwich de Goldfish
fuente

6

Las otras respuestas señalaron correctamente que la gestión de paquetes y el sistema operativo son ideas separadas, pero no mencionaron una solución.

El sistema de administración de paquetes más similar a apt-get o yum en Windows actualmente sería Chocolatey . Permite a las personas instalar / desinstalar paquetes (msi, exe, scripts de powershell) y esos paquetes pueden contener información sobre sus dependencias que Chocolatey puede resolver automáticamente.

El paquete generalmente contiene un enlace a los binarios y scripts para administrar el proceso de instalación. El paquete también puede contener los archivos binarios o cualquier otro archivo requerido (las dependencias deben estar en un paquete separado). Chocolatey también puede usar sistemas de administración de paquetes externos como el Instalador de plataforma web de Microsoft , Ruby Gems, Python, etc.

— AllenSanborn
fuente

¡Absolutamente! Hay un puñado de administradores de paquetes de terceros que también se ejecutan en Windows. El único que puedo nombrar en la parte superior de mi cabeza es NuGet, es un administrador de paquetes / dependencias para desarrolladores de aplicaciones integrado en Visual Studio. Dicho esto, creo que la pregunta era más sobre cómo el sistema operativo maneja los paquetes, dónde estas soluciones son más sobre cómo un usuario podría manejar los paquetes.

— Goldfish Sandwich

Lo siento, no incluí información sobre Chocolatey. Chocolatey se basa en Nuget. Nuget y Nuspec son solo un paquete de 'cosas' y una especificación de dependencias. En el caso de un marco de software como .Net (ruby, node, ...), las dependencias suelen ser componentes de software (dll, exe, js, ...). Esos son todos los componentes que usa una aplicación.

— AllenSanborn

En el caso de Chocolatey, aunque el paquete es una aplicación completa o una dependencia de la aplicación (marco de aplicaciones como java, .net, ruby). El paquete Nuget contiene scripts de PowerShell (opcionalmente también el instalador) que administrará la instalación de la aplicación y el archivo Nuspec describe la aplicación y qué dependencias tiene, por ejemplo, Powershell depende de .Net. También hay Boxstarter que enfoca un nivel más alto al describir la configuración de una máquina y de qué depende. Cosas muy bonitas. Boxstarter entra en el ámbito de lo que la gente usa Chef o Puppet.

— AllenSanborn

0

Por lo que entiendo, las únicas dependencias manejadas por Windows son las bibliotecas específicas de Microsoft. Si instala, como ejemplo, un programa de código abierto en Windows como Blender, tendrá las bibliotecas libavcodec y ffmpeg en sus propios archivos dll separados, y si instala, por ejemplo, OpenShot, instalará su propia copia del libavcodec en su propio directorio, y pueden ser versiones completamente diferentes. Esto puede ser una pesadilla al desinstalar software para limpiar la basura dejada atrás, y también ocupa mucho más espacio en disco con redundancia de biblioteca.

— Jeff
fuente