Perché Microsoft spedisce ancora VBA all'interno dei prodotti Office, invece di integrare .NET direttamente? [chiuso]

So che è possibile chiamare il codice .NET dal tuo codice VBA, ma perché VBA continua a esistere? L'unica ragione a cui posso pensare è l'eredità.

Ho dovuto solo ordinare un Scripting.Dictionarye la quantità di codice necessaria era spaventosa.

L'IDE sembra Visual Studio 2003. E ci sono molti piccoli dettagli che ti fanno impazzire (come cambiare la linea e ricevere un avviso a causa di un errore di compilazione). Oppure, se apri più di un foglio di calcolo, si mescola nel tuo "VBAProject" e questo è davvero confuso.

L'intera divisione modulo / modulo di classe / modulo non è poi così male, ma finisco sempre per scrivere direttamente la logica nei moduli o avere un enorme modulo che gestisce tutto.

Perché non posso premere Alt + F11 e hackerare in C #?

Microsoft Office offre diversi modi per consentire di modificare / migliorare il comportamento predefinito a livello di codice. VBA è un linguaggio testato in battaglia, collaudato e ampiamente diffuso per gli script in-doc. Molte persone in ufficio conoscono VBA e lo usano, mentre non conoscono linguaggi di programmazione più complessi come C #. Office non verrebbe venduto tanto se i clienti dovessero riscrivere un sacco di vecchi documenti abilitati per le macro che svolgono attività critiche per l'azienda, dopo aver appreso una nuova lingua o altro. La compatibilità all'indietro è una caratteristica fondamentale!

Uno stack .NET completo per Office probabilmente richiede un set di gestione delle dipendenze (dll: s, ecc.) E diventerà facilmente pesante da gestire per attività semplici - non è certo un'alternativa per gli script leggeri. VSTO ti dà la possibilità di utilizzare C #, ma al prezzo di un ciclo di sviluppo di plugin più pesante.

Un responsabile di programma di Microsoft ha scritto su questo qui . È chiaro che VBA è e sarà ancora in giro per piccoli scopi di scripting.

Bene, la risposta non è strettamente "eredità". La risposta è che VBA non è né VB6 né VB.Net: è VBA. Un linguaggio separato, ma correlato. Se sostituito VBA con VB.Net, inevitabilmente romperebbe molti DOCUMENTI.

Sostituire VBA con VB.Net porterebbe quasi sicuramente alla perdita di dati per un numero significativo di utenti dei loro prodotti principali - non è una buona cosa.

E il loro mercato di riferimento per VBA non sono i programmatori.

Se consideri il motivo principale per cui le persone acquistano Office è mantenere la compatibilità con tutti i documenti esistenti, molti dei quali contengono macro e VBA, sarebbe una Microsoft molto coraggiosa trattare quegli utenti come se avessero fatto la folla VB6 e dire loro di succhialo e inizia a scrivere codice in .NET, dai un'occhiata alla richiesta di n. 1 in assoluto !

Immagino che i ragazzi di LibreOffice si rallegrerebbero nell'incoscienza!

VBA è per la produttività in Office, non per "programmare". Il giorno in cui hai bisogno di più energia dai tuoi documenti è il giorno in cui assumi un programmatore per riscrivere tutto. Suppongo che un altro motivo sia il motivo per cui le macro di Visual Studios non sono neanche .NET. Pensa all'oggetto COM devenv4 come non molto diverso da VBA.

Penso che ci sia una leggera, ma importante, differenza tra eredità e popolarità . E quando hai fatto tutti i contratti che ho, scopri che VBA è follemente popolare :) Non posso dirti quanti contratti ho fatto per "fantini di Excel" che non sanno nulla di programmazione ma può schiacciare VBA come se fosse una questione di vita o di morte.