Nel mondo di .Net, codice gestito e web c'è ancora posto per VBA?

Ovviamente ce n'è ancora bisogno.

Perché .net la cosa importante? Perché rende lo sviluppo di app visive facile e veloce - MS ha imparato tutto questo da Borland e così è nato .net. (Borland aveva uno dei pochi ambienti di sviluppo visivi davvero semplici che potevano rendere eseguibili nativi win32).

Tutte queste altre cose e strumenti sono ancora necessari - la necessità di app native per win32 è comunque qualcosa che stimola argomenti appassionati. Direi che la necessità di app native per Win32 non andrà mai via. Questo è un problema secondario, ma correlato.

Se vuoi generare un'app / automazione per word, excel, access, visio, etc etc, allora VBA è veloce, semplice e strettamente integrato. Perché dovrebbe andare via? Diamine, puoi ancora fare macro di Excel del tipo che è andato fuori moda 15 anni fa. Nessuno lo fa perché ci sono altri modi migliori / più veloci / più facili da capire.

Ogni strumento ha il suo posto - se si cerca di utilizzare un altro punto al posto di VBA richiede più tempo / costa di più / è più difficile di quanto effettivamente cerchi di bloccare i pioli quadrati nei fori rotondi.

Il business del software è PIENO di persone con Sindrome di Hammer. Tu conosci quello: "Per un uomo con un martello tutto il mondo sembra un chiodo". Bene, ogni nuova tecnologia s / w ha i suoi folli devoti appassionati che pensano che risolverà ogni problema conosciuto dall'uomo, e poi alcuni. Hanno sempre torto. Lo sono sempre stato, lo sarà sempre.

Ho vissuto con questo problema negli ultimi anni. VBA è praticamente morto, eppure il modello VSTO per me è stato proprio come hai detto tu: buggy, inflessibile e lento. Quindi l'ho visto come una scelta per portare a termine il lavoro in modo rapido ed efficace, ma lasciare che le mie competenze professionali stagnino o svolgere il lavoro in modo doloroso ma allo stesso tempo sviluppare competenze che saranno disponibili in futuro.

La mia scelta è stata quest'ultima (VSTO), ovvero fino a quando Microsoft ha iniziato a cambiare la strategia generale a partire da circa un anno fa dallo sviluppo esclusivo proprietario (.NET), fino ad abbracciare il resto della comunità di sviluppo (C ++, javascript, html, eccetera). A quel punto il modello VSTO del futuro non sembrava così concreto. Quindi ho detto di fanculo, sono tornato a VBA veloce e facile.

Alcuni mesi più tardi e la mia scelta è stata ripagata: Microsoft ha annunciato che le "app" di Office 2013 o l'automazione possono essere create in javascript. Osservando le altre tendenze (Typescript, asp.net abbracciando js, html) sembra che questa potrebbe essere la lingua preferita da microsoft per l'ufficio in futuro. Sembra anche che non investiranno molto nella piattaforma VSTO andando avanti.

Quindi tl; dr : se sei principalmente uno sviluppatore di applicazioni per ufficio, continua con vba, impara js quando hai tempo e aspetta che la tua azienda si aggiorni a Office 2013.

Aggiornamento:

Così Office 2013 è stato distribuito e l'API di Javascript è stata gravemente priva di funzionalità. Nel suo stato attuale, non credo che possa sostituire VBA tranne che per le applicazioni più rudimentali.

Aggiornamento agosto 2015:

JS Office Apps è uscito da qualche anno. Durante questo periodo ho atteso che l'Api si espandesse allo stesso livello di funzionalità di quello che abbiamo con VBA / VSTO. Mentre ho sentito voci secondo cui Office 2016 porterà più funzionalità API per l'ecosistema di Office Apps, l'API non è realmente evoluta per supportare le tue applicazioni di automazione LOB standard. Da ciò che Microsoft ha rilasciato finora (comprese le nuove API di Office rinnovate) sembra che non siano focalizzati su questo. Speculare qui, ma sembra che Microsoft consideri le app di Office come un'interfaccia per il web / cloud / negozio online. Le app di Office non sono pensate per essere un'applicazione al punto da fornire una finestra per un'applicazione. L'attenzione è anche sull'interattività dell'utente, al contrario dell'automazione. Questo è fondamentalmente diverso rispetto al modello VBA / VSTO, che considera Office come l'applicazione, è una propria applicazione autonoma. Non mi aspetto che Apps possa supportare i casi di utilizzo di VBA / VSTO in qualsiasi momento. Ricordo di aver letto che Microsoft voleva che l'automazione di un ufficio pesante si estinguesse, probabilmente a causa dei rischi per la sicurezza, tra le altre cose. Ora utilizzo VSTO per l'automazione di Office.

Se me lo avessi chiesto due giorni fa, avrei risposto di no, VBA è completamente in uscita. Ma l'altro giorno ho aperto una delle mie vecchie applicazioni Excel e ho scoperto che tutte le dichiarazioni dichiarative di VBA erano state interrotte. Risulta che Office 2010 includa una nuova versione di VBA, 7.0, che modifica leggermente la sintassi. Sono rimasto davvero sorpreso dal fatto che MS abbia rilasciato una nuova versione e ora mi chiedo davvero quale sarà il suo futuro. Tuttavia, anche se VBA fosse sulla buona strada per VB6, penso che ci sarebbe stato bisogno dello sviluppo VBA per un po 'di tempo, data la grande quantità di applicazioni legacy per l'ufficio.

Personalmente, ho una preferenza piuttosto strong per vsto. Non sono un fan della sintassi di VB, quindi è bello sviluppare applicazioni office con C #. Inoltre, usando l'ufficio IDE mi sento come se stessi codificando nei periodi bui. Ora, non ho fatto una quantità enorme di vsto sviluppo, ma il problema più grande che ho riscontrato è una relativa mancanza di documentazione per certe cose. Per esempio, mi ci sono voluti ore di googling l'altro giorno solo per trovare un elenco definitivo di firme di callback per il nastro. Ci sono altri motivi, ma quelli sono i primi che vengono in mente. È anche possibile che le tue difficoltà con vsto siano solo legate al riapprendimento di come fare le cose. So di avere avuto la mia giusta dose di momenti frustranti che cercavano di fare qualcosa di "semplice" e di aver impiegato ore.