Pourquoi Microsoft envoie-t-il toujours VBA dans les produits Office, au lieu d'intégrer directement .NET? [fermé]

Je sais qu'il est possible d'appeler du code .NET à partir de votre code VBA, mais pourquoi VBA continue-t-il d'exister? La seule raison pour laquelle je peux penser est l'héritage.

Je devais juste trier un Scripting.Dictionaryet la quantité de code nécessaire était effrayante.

L'IDE ressemble à Visual Studio 2003. Et il y a beaucoup de petits détails qui vous rendent fou (comme changer la ligne et recevoir un avertissement à cause d'une erreur de compilation). Ou, si vous ouvrez plus d'une feuille de calcul, elle se mélange à vous "VBAProject" et c'est vraiment déroutant.

L'ensemble de la division module / module de classe / formulaire n'est pas si mal, mais je me retrouve à chaque fois avec l'écriture directe de la logique dans les formulaires, ou avec un énorme module qui gère tout.

Pourquoi ne puis-je pas appuyer sur Alt + F11 et pirater en C #?

Microsoft Office a plusieurs façons de vous permettre de modifier / améliorer le comportement par défaut par programme. VBA est un langage éprouvé, éprouvé et largement répandu pour les scripts in-doc. De nombreux employés de bureau connaissent VBA et l'utilisent, alors qu'ils ne connaissent pas de langages de programmation plus complexes comme C #. Office ne serait pas vendu autant si les clients devaient réécrire des charges de vieux documents compatibles avec les macros qui font des choses critiques pour l'entreprise - après avoir appris une nouvelle langue ou autre chose. La compatibilité vers l'arrière est une caractéristique clé!

Une pile .NET complète pour Office nécessite probablement un certain ensemble de gestion des dépendances (dll: s, etc.) et sera facilement lourde à gérer pour des tâches simples - ce n'est guère une alternative pour un script léger. VSTO vous donne la possibilité d'aller avec C #, mais au prix d'un cycle de développement de plugin plus lourd.

Un gestionnaire de programme chez Microsoft a écrit à ce sujet ici . Il est clair que VBA est et sera toujours là pour de petits scripts.

Eh bien, la réponse n'est pas strictement "héritée". La réponse est que VBA n'est ni VB6 ni VB.Net: c'est VBA. Une langue séparée, mais liée. Si VBA était remplacé par VB.Net, cela briserait inévitablement beaucoup de DOCUMENTS.

Le remplacement de VBA par VB.Net entraînerait presque certainement une perte de données pour un nombre important d'utilisateurs de leurs produits principaux - ce n'est pas une bonne chose.

Et leur marché cible pour VBA n'est pas les programmeurs.

Si vous considérez que la principale raison pour laquelle les gens achètent Office est de conserver la compatibilité avec tous les documents existants, dont beaucoup contiennent des macros et VBA, ce serait un Microsoft très courageux de traiter ces utilisateurs comme ils l'ont fait pour la foule VB6 et de leur dire de Sucez-le et commencez à coder en .NET, jetez simplement un œil à la demande de service utilisateur n ° 1 !

J'imagine que les gars de LibreOffice se réjouiraient cependant de s'évanouir!

VBA est pour la productivité dans Office, pas pour la "programmation". Le jour où vous avez besoin de plus de puissance de vos documents est le jour où vous embauchez un programmeur pour tout réécrire. Je suppose qu'une autre raison est que les macros de Visual Studios ne sont pas non plus .NET - pensez à l'objet COM devenv4 comme pas très différent de VBA.

Je pense qu'il y a une légère mais importante différence entre l' héritage et la popularité . Et quand vous avez fait autant de contrats que moi, vous apprenez que VBA est incroyablement populaire :) Je ne peux pas vous dire combien de contrats j'ai fait pour des "jockeys Excel" qui ne connaissent rien à la programmation mais peut écraser VBA comme si c'était une question de vie ou de mort.