MSI vs les packages nuget: c'est mieux pour la livraison continue?

Nous allons discuter de la rubrique suivante. Il est l'application qui est actuellement en cours de déploiement avec bon à savoir xcopy méthode.Cette approche rend difficile de gérer les dépendances, les mises à jour de fichiers, etc. Il y a idée de commencer le déploiement de l'application avec l'aide de certains paquets, vous savez, comme vous le faites dans Linux avec l'aide de RPM, mais pour Windows.

Donc, j'ai une question: quel système de paquets est préférable de l'utiliser sur windows classique de windows installer (msi) ou nuget ou autre chose?

NuGet et Windows Installer servir à deux fins différentes.
Peut-être que vous pensez plus Chocolaté. Ils le décrivent comme "un peu comme apt-get". Chocolaté utilise nuget à faire, c'est de la magie. Mais si vous regardez Chocolatey.org nombreux paquets contiennent simplement une Powershell-commande qui télécharge et installe un .MSI (ou une .EXE qui contient une .MSI)
Peintre Si vous pouvez expliquer le but de NuGet et en quoi elle diffère de MSI ,il sera utile. Avez-vous des bolg entrée comme ça? Je suis nouveau sur NuGet et je veux comprendre pourquoi ils sont à l'aide de NuGet lorsque MSI mécanisme est déjà là.
MSI est sur le déploiement des packages de logiciels pour la plateforme Windows. Nuget est de consommer des paquets SDK de Visual Studio plate-forme.

OriginalL'auteur Vadym Fedorov | 2014-07-28

  1. 25

    MSI est également accepté d'applications d'entreprise standard. Il a certains grands bénéfices de l'entreprise (et le court, concis version) par rapport à l'héritage de déploiement
    des techniques. WiX est le nouveau open source pour créer des fichiers MSI.

    D'Autres Outils:

    Bonjour tout le Monde & Bonjour WiX:

    Plus D'Un Exemple De Code:

    WiX de Démarrage Rapide: Voici quelques-uns des meilleurs exemples de code les liens que j'ai trouvé au fil du temps pour WiX:

    Et enfin:

    Quelques bonnes départ liens pour en apprendre Wix:

    Extraire des Fichiers à partir de Setup.exe WiX Bundle ou à partir d'un fichier MSI lui-même:

    Comme je l'ai écrit dans mon "Wix de démarrage rapide" post ci-dessus: Wix est les mains sur. Suffit de se concentrer sur simple, mais complète dans le monde réel des échantillons comme l'un de Codeproject - la lecture de la documentation seul est susceptible d'être une simple source de confusion.

    L'accent sur la division de votre application en composants et configurer une mise à jour majeure. Utiliser un fichier par composant comme une règle du pouce, et de lire cette réponse pour une meilleure compréhension de la création de composant: Changer mon GUID du composant dans wix?

    Une mise à jour majeure est le plus couramment utilisé mécanisme de mise à jour pour le logiciel déployé (l'autre type de mise à niveau est mise à jour mineur). Il est évidemment essentiel que vous pouvez mettre ce que vous avez déployé déjà. Obtenir des scénarios de mise à niveau de travail avant de déployer votre première version du logiciel de sorte que vous avez confiance dans votre déploiement de la solution.

    Une fois que vous avez vos composants et de mise à niveau de votre solution fonctionne, le reste des pièces de l'automne en place pendant que vous travaillez votre chemin à travers votre application en matière de déploiement et de vérifier pour les échantillons sur la Wix tutoriel site: https://www.firegiant.com/wix/tutorial/.

    Pour ceux qui écrivent Wix code directement (sans passer par un éditeur de GUI), je vous suggère de vérifier cette réponse pour un moyen de garder vos fichiers source laconique: La syntaxe pour les guid dans WIX?

    Plus de lecture:

    OriginalL'auteur Stein Åsmul

  2. 3

    Im va dans cette voie aujourd'hui, où j'ai hérité d'un logiciel en utilisant MSI/WiX pour l'installateur, mais en regardant la conversion de notre processus continu de livraison et de pousser les mises à jour sont installées, sans interaction avec le client. Je pense qu'il est incorrect de pigeon hole nuget comme un SDK de l'outil, dans son essence, c'est un outil pour déployer versionnées ensembles de fichiers. En outre, si le logiciel que vous déployez réponses lourdement sur nuget déjà, et vous êtes déjà à l'emballage de vos assemblées en paquets nuget pour un usage interne, alors pourquoi rajouter de la technologie dans le mélange pour l'amour d'elle? package un nuget.exe dans votre msi, appelez-mise à jour périodiquement, en fait.

    Je sais WiX prend en charge la création de patchs, mais il semble comme une réflexion après coup. En outre, ce qui se passe si votre patch d'échec de l'installation? L'installation des correctifs de commande? Votre principal programme d'installation nécessite l'UAC autorisations, alors que le patch ne fonctionne pas?

    je pense que les temps sont en train de changer, et MSI représente une ancienne façon de penser les choses. Chocolaté est un bon exemple, mais sa reste à cet hybride stade, le mélange des deux technologies.

    MSI est plus comme pull - u obtenir un paquet, puis l'installer.
    Nuget est plus comme une poussée stratergy - u obtenir le nom d'un paquet, l'installer, puis périodiquement u peut appeler la mise à jour, et une nouvelle version est téléchargée et installée.

    D'accord, je resterais loin de corriger les paquets (.msp). Une application que j'ai écrit il y a des années utilisé .msp comme un mécanisme de mise à jour et régulièrement endommagé l'installation. Pour le plaisir, je regardais à travers mon registre pour les applications utilisées .msp application de correctifs (à partir de centaines d'applications installées) et a trouvé exactement 1... mon propre.

    OriginalL'auteur Weq