2012-09-25 10 views
10

Attualmente sto lavorando a un componente aggiuntivo Excel 2010 che in precedenza era un componente aggiuntivo di Excel 2007. Da qualche parte nel processo di commutazione dei computer, il componente aggiuntivo è stato convertito, credo.convertire un add-in Excel 2010 in un componente aggiuntivo 2007 (entrambi VSTO)

Alcuni dei miei clienti hanno dichiarato che il componente aggiuntivo non funzionava più su Excel 2007, quindi ho provato a eseguire il debug in un VirtualBox con Excel 2007 e Visual Studio 2010 installati.

Ora ho il messaggio di errore:

Non è possibile eseguire il debug o eseguire questo progetto, perché la versione richiesta dell'applicazione Microsft Office non è installato.

ho iniziato un nuovo progetto componente aggiuntivo Excel 2007 e ha cercato di trovare quali siano le differenze e si avvicinò con l'idea che si ha in qualche modo a che fare con la DLL così ho cambiato il mio 2010 componente aggiuntivo fino a che non sembrava un 2007 addin.

Ricevo ancora il messaggio di errore che indica che il mio progetto non può essere sottoposto a debug.

C'è qualcosa che potrei aver dimenticato di cambiare.

Scrivere un addin completamente nuovo non è purtroppo un'opzione.

Queste domande non mi hanno aiutato finora:

  1. Excel Addin that works on Excel 2007 and 2010
  2. Deploying Office 2010 addin

risposta

8

Per ottenere VS 2010 lavorare con Office 2007 modificare il file di progetto (. csproj) in modo che si apra in Office 2007 e non cerchi Office 2010 quando viene eseguito (quindi il messaggio di errore sopra).

Qui è il cambiamento delle impostazioni del progetto (Excel esempio):

Fonte XPath:

// progetto/ProjectExtensions/VisualStudio/FlavorProperties/ProjectProperties/@ DebugInfoExeName

Old Value (Office 2010):

DebugInfoExeName = "# Software \ Microsoft \ Office \ 14.0 \ Excel \ InstallRoot \ Path # excel.exe"

nuovo valore (Office 2007):

DebugInfoExeName = "# Software \ Microsoft \ Office \ 12.0 \ Excel \ InstallRoot \ Path # excel.exe"

Dopo aver modificato questa impostazione del progetto, quando si accende il debugger (F5) caricherà l'applicazione Excel 2007 invece di cercare Excel 2010.

+1

Grazie, questo suggerimento ha funzionato alla grande. – Bongo

+3

Sembra che i simboli # stiano semplicemente racchiudendo un percorso di registro - sembra che stia dicendo "trova questo percorso dal registro e aggiungi excel.exe". - Così ho deciso di clonare le mie impostazioni di registro dall'hive 12.0 nell'hive 14.0 e dargli un colpo. Lo 'ed ecco! Funziona! - Ora posso, con un file .sln/.csproj, aprire e debuggare lo stesso componente aggiuntivo sul mio Windows XP/Office 2007 VM come posso sulla mia VM Windows 7/Office 2010 (usando VSTO 4.0 ovviamente). – BrainSlugs83

6

In genere, quando sto sviluppando contro più versioni di Office con i componenti aggiuntivi di VSTO, ho un progetto per ogni versione di Office che ho scelto come target. Metto tutto il codice comune tra i progetti in un singolo progetto (tipicamente il progetto più vecchio) e utilizzo i file collegati, aggiungo il comune file ai nuovi progetti Questo mi consente di scrivere un set di codice core comune, astratto rispetto ai requisiti di ciascuna versione di Office. Ciò significa che non sto più combattendo i diversi modi in cui VST O è compilato per ogni versione di Office. Ciò può essere reso più semplice con le cartelle condivise e le macchine virtuali, quindi posso svilupparlo e testarlo senza più computer. Non è affatto grazioso, ma funziona bene per me. Ciò dovrebbe consentire di sviluppare il componente aggiuntivo VSTO sia in Office 2007 che in Office 2010 senza molti problemi.

+0

quindi, hai diverse versioni di Visual Studio su diverse VM, giusto? –

+1

@ T.Todua, a questo punto, non ricordo. Sono passati quasi 6 anni da quando ho lavorato a un componente aggiuntivo VSTO. Ricordo di aver utilizzato diverse VM per il progetto, quindi avrebbe avuto senso avere una VM per ogni ambiente per cui stavo sviluppando. –