2012-03-09 11 views

risposta

10

mono --debug non ha nulla a che fare con il debugger, semplicemente fa in modo che Mono tenga traccia delle informazioni di debug in modo che possa fornire informazioni su file/linea/colonna in backtrace.

Il comportamento di System.Diagnostics.Debugger.Break() dipende dalla versione mono. AFAIK nella sua forma base imposta un breakpoint difficile, quindi se la tua app non è in esecuzione in un hard debugger nativo si bloccherà semplicemente. Se la tua app è in esecuzione all'interno del Mono Soft Debugger con Mono 2.11 o successivo (che non è ancora stato rilasciato), imposterà un soft breakpoint per il debugger e funzionerà come previsto.

Il metodo di base per abilitare il debug di componenti aggiuntivi consiste nell'impostare un comando di esecuzione personalizzato nel progetto addin. Apri "Opzioni progetto", vai alla sezione "Esegui> Comandi personalizzati", aggiungi un comando personalizzato per "Esegui". Imposta l'eseguibile su MonoDevelop.exe e la directory di lavoro come directory contenente. Ciò significa che quando esegui/esegui il debug del tuo progetto, MD eseguirà effettivamente quell'eseguibile invece di eseguire direttamente il tuo progetto. Se MonoDevelop.exe carica il componente aggiuntivo, sarà possibile impostare punti di interruzione, passaggio, ecc.

La parte difficile è che MD carica l'addin. Un modo per farlo sarebbe quello di far sì che il progetto produca l'addin dll in una delle directory in cui MD cerca gli addin, ma è una cosa molto hacky da fare in fase di sviluppo. Una soluzione migliore consiste nell'utilizzare la variabile di ambiente non documentata MONODEVELOP_DEV_ADDINS per specificare una directory aggiuntiva da cui caricare i componenti aggiuntivi per MD. Non c'è un'interfaccia utente in MD per l'impostazione di env vars per i comandi personalizzati, ma è supportata internamente: dovrai modificare manualmente il file csproj.

trovare la parte che assomiglia:

<CustomCommands> 
    <CustomCommands> 
    <Command type="Execute" 
     command="..\..\..\monodevelop\main\build\bin\MonoDevelop.exe" 
     workingdir="..\..\..\monodevelop\main\build\bin" /> 
    </CustomCommands> 
</CustomCommands> 

e modificarla in:

<CustomCommands> 
    <CustomCommands> 
    <Command type="Execute" 
     command="..\..\..\monodevelop\main\build\bin\MonoDevelop.exe" 
     workingdir="..\..\..\monodevelop\main\build\bin"> 
     <EnvironmentVariables> 
     <Variable name="MONODEVELOP_DEV_ADDINS" value="${TargetDir}" /> 
     </EnvironmentVariables> 
    </Command> 
    </CustomCommands> 
</CustomCommands> 

Se vi state chiedendo il motivo per cui gli elementi sono <CustomCommands> due profonde, che un bug noto.

+0

Grazie! Funziona come previsto. Ho collegamenti simbolici alla build di debug del componente aggiuntivo nella directory AddIns, quindi non ho provato MONODEVELOP_DEV_ADDINS – simendsjo

+0

@mhutch Punta fredda, grazie. L'impostazione di 'MONODEVELOP_DEV_ADDINS' funziona, ma solo una volta. A meno che non esca da tutte le istanze di MD, inclusa l'istanza con il progetto aggiuntivo, solo il primo componente aggiuntivo compilato verrà mai prelevato. C'è qualche caching aggiuntivo in corso? –

+0

Nota, questo è su OSX. In Windows funziona. Ogni nuova compilazione viene ripresa dal nuovo XS –

0

il debugger morbido non supporta ancora System.Diagnostics.Debugger.Break(), in modo che non funzionerà.

È sufficiente eseguire il debug di MonoDevelop in MonoDevelop e impostare i punti di interruzione sui file di origine del componente aggiuntivo.

+1

Potresti elaborarlo? 'Esegui> Debug Application> MonoDevelop.exe' non fa nulla .. – simendsjo