contratti di codice per .NET 3.5 scombina debugger di VS10

Question

Ho recentemente migrato un sacco di test pre-condizione manuali ed eccezione gettando con contratti di codice. Invece di aggiornamento a .NET 4, sono stato utilizzando l'assemblaggio Microsoft.Contracts.dll così ho potuto attaccare ad NET 3.5 un po 'più lungo (si tratta di una libreria che viene utilizzato sia da .NET 3.5 e .NET 4 gruppi). Ho impostato i contratti di riscrittura in Visual Studio 2010 e i contratti funzionano perfettamente.

Tuttavia, da quando ho eseguito questa opzione, ho notato che il debugger si comporta in modo divertente nei metodi con i contratti, specialmente nelle classi con un metodo ContractInvariantMethod. Il cursore di esecuzione non sembra corrispondere sempre alla linea evidenziata, alcuni punti di interruzione non riescono a essere colpiti e ho avuto un metodo in cui il debugger non poteva dire i nomi delle variabili locali e mostrava cose come CS$1$0000. Questo è in build di debug.

Ci sono problemi noti su come utilizzare i contratti di codice in Microsoft.Contracts.dll in .NET 3.5 tramite VS10? Problemi simili si presentano con i contratti di codice in .NET 4?

[Edit] Questa domanda mi portano a creare un bug su Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/573983/code-contract-rewriting-messes-up-local-variable-names-in-iterator-methods-while-debugging

Answer 1

Spero che tu sappia cosa è la riscrittura del contratto: codice generato — extra al volo che non ha alcun codice sorgente per il compilatore da aggancio. Con CLR che ha così tanti elementi diversi, c'è un certo numero di cose che il debugger non farà affatto o si confonderanno e solo le cose che sono caratteristiche del linguaggio completo con un impatto ampio ottengono il budget per il supporto completo del debugger. Ad esempio, espressioni lambda.

Il che non vuol dire che archiviare un bug non è per una buona causa, solo che non ci si deve aspettare che qualcosa cambi meglio quando si utilizza un aspetto che non è ancora completamente sviluppato. Essere early adopter ha sempre quel tipo di costo, ma anche i diritti di vanteria :-)

Answer 2

hanno in mente, che i contratti di codice attualmente non funzionano con condizioni post & multithreading. limitare i contratti per eseguire solo la riscrittura delle condizioni preliminari. che ha risolto molti problemi nel nostro sistema.