Devrais-je m'inquiéter de la redistribution du runtime .NET avec mon application?

Question

Je voudrais éviter si possible de redistribuer le runtime .NET avec mon application car cela augmenterait la taille de l'application, le temps de téléchargement, le temps de développement & amp; introduira éventuellement de nombreuses erreurs de déploiement différentes. Microsoft oblige-t-il les utilisateurs à mettre à jour le runtime .NET via Windows Update? Si non, quelles sont les options pour redistribuer le runtime .NET? Microsoft at-il facilité la redistribution du runtime avec les applications .NET? En outre, le runtime .NET est-il garanti rétro-compatible?

Je ne fais que résumer les réponses ici. On dirait que nous devons avoir un programme d'amorçage pour vérifier au moins l'existence du temps d'exécution .NET. L'option alternative consiste à empaqueter le runtime et à le déployer s'il n'existe pas. Il existe plusieurs options pour empaqueter & Amp; Visual studio fournit une option pour construire un projet d'installation avec le moteur d'exécution. Il existe également d'autres options de conditionnement telles que InnoSetup, WIX, etc. (vous ne savez pas quelle option est la meilleure et la plus gratuite). L'installation à l'exécution nécessite un redémarrage et l'option d'installation choisie doit reprendre l'installation de l'application après le redémarrage.

Answer 1

De plus, vous devriez vous en inquiéter. Sans le temps d'exécution, votre application ne fonctionnera mystérieusement pas. Ne supposez jamais qu’une version particulière du moteur d’exécution est préinstallée.

Comme indiqué ci-dessus, l’assistant de projet d’installation dans VS créera un fichier d’installation qui ne le téléchargera que si nécessaire. NSIS et Inno Setup ont des scripts qui feront la même chose. Notez que vous devrez gérer le redémarrage et la configuration continue lors de l'installation du moteur d'exécution. Je crois que l’assistant d’installation s’occupe de cela pour vous.

Answer 2

Créez simplement un projet Windows Installer. Vous devriez avoir cela en option dans VS2005 et VS2008. Lors de l'installation de votre application, il s'assurera que le système dispose du runtime .NET et de tout autre logiciel requis à cet égard. Cela l'ajoutera à votre package d'installation, pas à votre application. C’est généralement ainsi que vous installez vos applications ou utilisez Install Shield.

Voici un guide .

texte de remplacement http://img154.imageshack.us/img154/2066/newprojectr .png

Answer 3

Lorsque vous créez votre package d'installation, l'installation ne sera exécutée que si cela est nécessaire. c'est-à-dire pas déjà sur le système (ou une version incorrecte)

Éditer: Oui, vous devriez créer ce paquet, cela vous facilitera grandement la vie. Pour ce faire, VS utilise File - & Gt; Project et sélectionnez intstaller project. L'assistant vous guidera à travers les options.

Answer 4

En utilisant une sorte d’amorçage, vous pouvez vérifier si .NET est installé et le télécharger si nécessaire.

Par exemple, avec le démarrage MSI Factory (je ne préconise pas MSI Factory, c’est un programme moche, mais le logiciel d’amorçage qu’il accompagne en vaut à lui seul le coût de la licence si vous développez un logiciel commercial comme le nôtre), il existe des scripts que vous pouvez simplement inclure pour exécuter cette fonction. Nous utilisons WiX + le programme d’amorçage MSI Factory pour distribuer à la fois un seul fichier EXE compressé (30 Mo) et un petit 1 Mo & "Téléchargeur &"; EXE qui télécharge un MSI. Les deux EXE vérifient la présence de .NET 2.0 et le téléchargent si nécessaire. Nous distribuons également un fichier MSI autonome qui vérifie également .NET et bloque l'installation en cas d'absence.

Vous avez essentiellement les éléments suivants:

• Windows XP - n’est pas livré avec .NET. Le client doit l’installer manuellement (il s’agit d’un composant facultatif de Windows Update)
• Vista - est livré avec .NET 2.0 (mais pas 1.1)
• Server 2003 - livré avec .NET 1.1

Ignorer .NET 1.1, juste l’ignorer. Les utilisateurs de Vista et au-delà ne l'auront installé que pour le support des applications héritées ou s'ils sont un développeur.

.NET 2.0 est la version la plus couramment installée. D'après notre base d'utilisateurs, moins de 10% des utilisateurs ont installé .NET 3.5. Si votre application cible un public technique et geek, je dirais qu'environ 50% des utilisateurs disposeront de .NET 3.0. Si vous ciblez un marché grand public / de détail / non technologique, vous pouvez probablement en évaluer environ 30% avec .NET 2.0 et 10% avec .NET 3.0 ou version ultérieure.

Les chiffres ci-dessus sont basés sur le trafic de navigateurs de nos sites Web, un public principalement non technique. C'est probablement le meilleur moyen de se faire une idée de votre marché. IE signale toujours la version .NET dans la chaîne User-agent. Eclatez donc les weblogs et commencez l’analyse:)

Answer 5

Cela dépend. Là où je travaille, nous l’incluons dans le programme d’installation en tant que condition préalable, car certains de nos clients n’ont peut-être pas de connexion Internet pour télécharger le moteur d’exécution.

Quelques choses que vous pouvez faire:

1. Incluez un test de la version de .NET sur la machine cible et quittez l'installation si elle n'y est pas.
2. Créez une version de l'installation qui inclut le runtime .NET et l'installera si nécessaire.
3. Créez une version de l'installation qui téléchargera le runtime .NET et l'installera si nécessaire.

Si je savais que mes clients étaient tous en ligne, je choisirais l'option 3 pour .NET ainsi que tout autre préalable, comme Crystal Reports ou SQL Express. J'ai des installations où j'ai ce qui est inclus et l'installation est plus de 100 Mo. 70 Mo + sont des conditions préalables.