Esiste una soluzione tattica (leggi "hack") per evitare di avere il codice VBA e il foglio Excel come un file binario?

Question

Come ho capito quando creo un foglio Excel con codice VBA il codice VBA viene salvato come binario con il foglio. Pertanto non posso inserire il codice nel controllo del codice sorgente in modo utile, avere più sviluppatori che lavorano sui problemi, diffondere è difficile, ecc.

C'è un modo per aggirare questo senza passare a VSTO, addin COM ecc.? Per esempio. perché il foglio da caricare è VBA in fase di esecuzione da un servizio Web, un'unità condivisa, ecc.? Qualche idea apprezzata.

Grazie.

Answer 1

Ho scritto una sorta di sistema di compilazione per Excel che importa il codice VBA dai file di origine (che può essere quindi importato nel controllo del codice sorgente, diffed, ecc.). Funziona creando un nuovo file Excel che contiene il codice importato, quindi potrebbe non funzionare nel tuo caso.

La macro costruzione assomiglia a questo, ho salvarlo in un file chiamato Build.xls:

Sub Build() 
    Dim path As String 
    path = "excelfiles" 

    Dim vbaProject As VBIDE.VBProject 
    Set vbaProject = ThisWorkbook.VBProject 

    ChDir "C:\Excel" 
    ' Below are the files that are imported 
    vbaProject.VBComponents.Import (path & "\something.frm") 
    vbaProject.VBComponents.Import (path & "\somethingelse.frm") 

    Application.DisplayAlerts = False 
    ActiveWorkbook.SaveAs "Output.xls" 
    Application.DisplayAlerts = True 

    Application.Quit 
End Sub 

Ora, significa che la roba VBIDE è necessario importare un riferimento denominato “Microsoft Visual Basic per Applications Extensibility 5.3 " penso che

Naturalmente avete ancora il problema di avere per avviare Excel per costruire questo può essere risolto con un piccolo script VB:..

currentPath = CreateObject("Scripting.FileSystemObject") _ 
    .GetAbsolutePathName(".") 
filePath = currentPath & "\" & "Build.xls" 

Dim objXL 
Set objXL = CreateObject("Excel.Application") 
With objXL 
    .Workbooks.Open(filePath) 
    .Application.Run "Build.Build" 
End With 
Set objXL = Nothing 

Ru lo script precedente dovrebbe avviare il file Excel di compilazione che restituisce il foglio risultante. Probabilmente dovrai modificare alcune cose per renderlo mobile nel file system. Spero che questo ti aiuti!

Answer 2

Interessante domanda ... abbiamo anche un problema con il controllo del codice sorgente VBA ma non abbiamo mai avuto il problema di affrontarlo.

Questo Microsoft KB article corrisponde ai tuoi criteri? Il codice viene inserito in un file .BAS che può trovarsi in una posizione arbitraria (e separato dal file .xls).

Come ho già detto, non ho mai provato a farlo ma sembra che questo sia un approccio.

Answer 3

Si consiglia vivamente di provare a caricare VBA in fase di esecuzione. L'automazione VBIDE è alquanto instabile e penso che si verificheranno un sacco di problemi di manutenzione e supporto.

La mia soluzione era quella di esportare il codice peridocalmente per il controllo del codice sorgente come file di testo. Rimuoverò anche tutto il codice da xls (rimozione completa di moduli, moduli e moduli di classe e cancellazione del codice nei moduli Foglio di lavoro e cartella di lavoro) e metto solo questo 'stub' xls nel controllo del codice sorgente.

Una ricostruzione dal controllo del codice dovrebbe consistere nel prendere gli xls "stub", importare tutti i moduli, i moduli di classe e i moduli e copiare e incollare tutto il codice nei moduli Foglio di lavoro e Cartella di lavoro.

Mentre si è trattato di un processo doloroso, ha consentito il corretto controllo del codice sorgente con tutte le normali funzionalità di diffocalizzazione, ramificazione, ecc. Sfortunatamente la maggior parte di esso era manuale. Ho scritto un componente aggiuntivo che ha automatizzato parte di questo, ma è stato risolto rapidamente con una soluzione, cioè piuttosto buggata e richiedendo un intervento manuale. Se mai dovessi tornare a rivederlo e farlo risalire a zero, ti farò sapere ;-)

Answer 4

Vorrei anche sconsigliarvi di caricare in fase di esecuzione e cercare uno strumento di stile make.Dopotutto, se il tuo codice è sotto controllo del codice sorgente, dovresti solo aggiornare le cartelle di lavoro dopo un commit.

Sfortunatamente, non esiste una tale utilità, o almeno non una che potrei trovare.

Answer 5

Penso che se confrontato con le alternative (ovvero ricostruendo costantemente file di cartelle di lavoro Excel) sarebbe molto meno fastidioso passare a VSIN o COM Addin, utilizzando VBA per il lavoro di prototipazione leggera. Si ottiene anche il vantaggio di non avere facilmente il codice sorgente "hackable" (cioè è necessario più di indovinare la password del progetto VBA)

Answer 6

Il percorso più breve in avanti sta usando SourceTools.xla Addin da http://www.codeproject.com/KB/office/SourceTools.aspx

Un altro approccio è quello di scrivere uno strumento simile utilizzando i collegamenti COM al tuo linguaggio di programmazione preferito. Un mio abile collega ne ha creato uno in Python in grado di esportare tutto ciò che include codice VBA, contenuto del foglio di lavoro e formule e persino riferimenti VBA in file di testo e potrebbe assemblare una cartella di lavoro fuori da questi. Anche prima del formato XLSX.