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?