Le cas pour ou contre .NET (la bête) [fermé]

L'entreprise pour laquelle je travaille utilise C ++ Builder 6. Nous développons du code natif depuis la conception. Notre produit phare est entièrement écrit en code natif.

Entre dans le .NET Framework avec ses cloches et ses sifflets. Je tombe, crochet, ligne et plomb. Je convainque la direction que .NET devrait absolument être notre nouveau cadre pour tout nouveau développement logiciel et que nous devrions commencer à migrer notre codeline existante dès que possible. Avec tous les avantages, il ne faut pas beaucoup convaincre. Ils acceptent ma proposition comme d'habitude.

À ce stade, je commence à développer ma toute première application .NET. Tout se passe comme prévu. Le projet n'est qu'un composant de notre produit. Et donc j'arrive au point de créer un installateur pour ce nouveau composant. En tant qu'entreprise, nous sommes fiers de rendre les choses aussi simples que possible pour l'utilisateur. Même Microsoft avec des milliers de développeurs ne crée pas d'installateurs comme nous le faisons. Lorsque vous installez Microsoft CRM par exemple, vous n'obtiendrez qu'une liste des échecs et des conditions préalables à installer avant de pouvoir continuer. Pas nous. Jamais. Si vous avez besoin de quelque chose, nous l'installerons pour vous.

Cela rend nos installations si faciles. .NET Framework n'est pas installé? Aucun problème! Nous le ferons pour vous. Besoin d'un client SQL natif? Bien!

Le problème est le suivant, maintenant qu'un seul composant de notre solution est écrit en .NET, cela complique incroyablement le processus d'installation. Avant même de pouvoir installer notre produit, je dois faire ce qui suit:

• Détecter si le prérequis est installé

• Installez-le si ce n'est pas le cas

• Vérifiez qu'il a été installé avec succès

• Prérequis suivant

Pour installer .NET Framework, j'ai d'abord besoin de Windows Installer 4.5. Mais il existe différentes versions pour les différents systèmes d'exploitation, donc j'ajoute la détection du système d'exploitation et lance le bon EXE. Oh, .NET Framework est déjà fourni avec 2k8 et l'exe du programme d'installation ne peut pas s'exécuter dessus, vous devez exécuter OCSetup.exe avec des paramètres pour l'installer.

Et ainsi de suite. Ensuite, SQL Express 2005 doit être installé. Les dépendances augmentent à nouveau.

Je soutiens avec la direction que même Microsoft ne facilite pas les choses pour l'utilisateur. Leur réponse est qu'il n'y a aucune raison pour nous de ne pas être meilleurs qu'eux de cette manière. Je ne peux pas contester cela, sauf que j'estime qu'il y a de très bonnes raisons pour lesquelles ils ont opté pour leur approche.

Du coup, notre installateur est énorme. Tous les prérequis pour .NET, sans même parler du support 64 bits qui a toute une gamme séparée d'EXE à installer. Alors maintenant, nous en arrivons au point où nous voulons que les utilisateurs puissent télécharger une évaluation "rapide". Quelle blague. Vous devez télécharger 500 Mo pour lancer une application de 30 Mo. La majorité du package d'installation est des prérequis.

La direction estime que nous avons trop de dépendances / prérequis. Je comprends totalement. Ils suggèrent que nous nous éloignions du framework .NET, pour revenir au pays natal où les choses étaient encore "faciles" en termes d'installation. C'est là que ma partie de moi veut défendre .NET en expliquant les avantages dans une vue d'ensemble, l'expérience de développement améliorée, la maintenance plus facile et la qualité globale du code. L'autre partie de moi est entièrement d'accord avec eux! Développer en .NET vous oblige simplement à installer trop d'autres prérequis, ce qui complique l'installation.

Oui, certains des partisans de .NET prétendront que tout doit être installé sur un système d'exploitation corrigé et mis à jour. C'est vrai, mais tous les clients ne l'ont pas et dire simplement "Je suis désolé, mettez à jour d'abord" ne suffit pas. N'oubliez pas que nous sommes fiers de l'expérience utilisateur globale.

Nous envisageons maintenant d'écrire à nouveau du code natif et je sais que nous perdons en termes de vitesse de développement et de tous les avantages de .NET. Mais nous gagnons dans ce domaine, qu'il soit petit si vous regardez la situation dans son ensemble ou non. Comme nous avons des compétences en développement de code natif et que .NET est en fait un nouveau terrain pour nous, il est même logique de revenir en arrière.

Ma question est la suivante: quel est le point de vue de votre entreprise sur ce problème si c'est même un problème et à quoi ressemblera l'analyse de rentabilisation que je propose à la direction en supposant que je souhaite continuer à migrer tous nos produits vers .NET?

C'est la raison pour laquelle de nombreuses entreprises ont opté pour des installateurs Web qui téléchargent tous les prérequis à la volée depuis votre page d'accueil. Puisque dans la plupart des cas, le système d'exploitation dispose de 99% de ce qui est nécessaire (s'ils ont été mis à jour à l'aide de Windows Update).

Je ne mettrais pas tout pour x64 et x32 dans le même programme d'installation. Créez deux installateurs, un pour chaque architecture.

Paint.NET encapsule correctement l'installation des prérequis sans regrouper par défaut le framework .NET. Le résultat final est un exécutable shim non géré qui vérifie le framework .NET et d'autres éléments et vous tient la main lors de son installation; tous téléchargés à la volée selon les besoins. Ils exécutent ensuite une application WinForms qui s'invoque dans MSI pour envelopper davantage l'installation dans du coton.

Vaut un Google.

Il est également probable que de nombreuses machines clientes auront déjà une version du .NET Framework installée car il fait partie de Microsoft Update, ce qui le rend plus facilement utilisable dans le monde des affaires.

Articles de blog Paint.NET sur l'installation:

http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/

http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (merci Rup!)

En lisant un peu plus l'histoire, la direction a vraisemblablement dû subir la douleur du déploiement avec l'application C ++ au moins une fois, mais c'est maintenant fait et classé comme «facile». Mettez du temps contre le déploiement et présentez-le à la direction et, en cachant la douleur, montrez-leur à quel point il est facile à installer :)

Revenons à la raison pour laquelle vous vouliez passer du code natif au code .NET en premier lieu: c'est plus efficace pour vous, en tant que programmeur. Beaucoup de choses sont plus faciles en .NET qu'en C ++ (ou dans le langage natif que vous utilisez), et vous pouvez donc développer vos applications beaucoup plus rapidement.

Ensuite, comment le temps que vous passez à développer l'application se compare-t-il au temps que vous passez à développer le programme d'installation? Même si vous devez passer quelques semaines à clouer le programme d'installation (en particulier la partie de configuration du framework), cela devrait être plus ou moins le seul moment où vous devez passer par cela.

Pour toutes les applications futures, vous utiliseriez un programme d'installation presque identique; vous feriez toujours toutes les vérifications préalables, mais au lieu de copier des fichiers dans C: \ Foo, vous copiez des fichiers différents dans C: \ bar.

À mon avis, c'est une simple question d'économie. Oui, il est plus coûteux de développer un programme d'installation (bon / complet) pour une application .NET, mais si c'est l'étape que vous devez franchir une fois pour améliorer considérablement votre temps de développement, c'est une évidence. Votre retour sur investissement serait probablement de l'ordre de quelques semaines.

Je sens que je dois répondre à cette déclaration:

Oui, certains des partisans de .NET prétendront que tout doit être installé sur un système d'exploitation corrigé et mis à jour. C'est vrai, mais tous les clients ne l'ont pas et dire simplement "Je suis désolé, mettez à jour d'abord" ne suffit pas. N'oubliez pas que nous sommes fiers de l'expérience utilisateur globale.

Si votre utilisateur insiste pour se tirer une balle dans le pied en exploitant un système que le vendeur a informé qu'il n'était plus adapté à son objectif , vous ne pouvez plus rien faire pour `` l'aider ''. Je suis conscient que cela me fait ressembler à un activiste désagréable, mais je le vois de la même manière qu'un commerçant manuel - c'est au client de s'assurer que l'environnement dans lequel il veut que je travaille soit son et approprié pour le produit. Si ce n'est pas le cas, j'accepterai une rémunération supplémentaire pour faire ce travail également, mais cela pourrait encore leur demander du travail supplémentaire parce qu'ils n'ont pas eu la prévoyance de s'assurer qu'ils comprennent ce qu'ils achetaient.

Je crois que les clients de logiciels ont été autorisés à rester dans l'ignorance assez longtemps et qu'ils devraient maintenant être tenus de comprendre ce qu'ils achètent. Exploiter un environnement informatique d'entreprise qui n'est pas correctement corrigé équivaut à continuer à faire fonctionner un véhicule qui a fait l'objet d'un rappel du fabricant - un service pack Windows équivaut à un rappel à bien des égards. Vous n'êtes pas légalement obligé de vous soumettre à un rappel, mais c'est dans votre meilleur intérêt en tant qu'entreprise et vous pouvez être tenu responsable des dommages causés par votre non-responsabilité.

Toute application Visual C ++ a également des prérequis / dépendances externes: runtime 6.0, 2003, 2005, 2008 ou 2010? pas de SP, SP1 ou SP2? x86 ou x64? Quelle est la version de Windows Installer requise par 2005 SP2? Et quel 2008 SP1? Et ainsi de suite, ainsi de suite.

Voilà donc des arguments farfelus! Comme les grognements de Joel à propos de .NET. Et regardez ce qui est maintenant !

Je ne vois pas comment il y a beaucoup plus de pré-requis pour .net sur C ++ Builder. Vous vous plaignez de SQL Server, mais vous ignorez le fait que vous devez également installer une base de données avec le générateur C ++. Vous vous plaignez de x64 vs x32, mais .NET ne nécessite aucun changement .. le même exe s'exécute sur les deux (et se compile de manière optimale pour l'un ou l'autre environnement). On ne peut pas en dire autant de C ++ Builder. Vous aurez peut-être besoin de versions séparées du serveur SQL, mais encore une fois, cela s'appliquerait au générateur C ++ (à moins que vous n'installiez simplement x32 sur tout).

Oui, il y a les problèmes de la nouvelle version du programme d'installation, mais ces composants ne sont pas très volumineux. Et vous pouvez vraiment demander aux installateurs de télécharger et d'installer uniquement les éléments nécessaires.

Le générateur C ++ est probablement plus facile pour vous car vous avez déjà investi du temps dans la création d'un bon programme d'installation. Vous devez faire de même pour .NET, puis vous pouvez choisir en fonction de problèmes réels ... et non de cela.

À propos, la raison pour laquelle Microsoft choisit de faire les choses comme ils le font est que de nombreux utilisateurs, en particulier les utilisateurs d'entreprise, n'apprécient pas que les choses soient installées automatiquement (peut-être parce qu'ils ont une application qui dépend d'une version spécifique d'une bibliothèque, et vous venez l'effacer avec une nouvelle version qu'ils ne peuvent pas facilement désinstaller).

Ce que vous considérez comme «faciliter les choses» pour les personnes moins bien informées rend en fait les choses BEAUCOUP plus difficiles pour ceux qui savent ce qu'ils font.

Voici un bon exemple. Une chose que je méprise absolument, c'est lorsque j'installe une application qui a besoin de SQL Server, et qu'elle installe sa propre instance de SQL Server, même si j'ai déjà plusieurs instances qu'elle pourrait utiliser. Facile pour le novice, une douleur dans le cul pour moi d'essayer de faire fonctionner votre application avec ma seule instance.

Si votre application s'exécute sous Mono, l'expédition de votre application avec l'environnement d'exécution Mono peut être moins pénible.