Passa ai contenuti principali

Evitare il debug all’interno di metodi o proprietà: DebuggerHiddenAttribute e DebuggerStepThroughAttribute

Gli attributi che analizzeremo in questo post servono per evitare che si possa eseguire debug all’interno di metodi o proprietà delle nostre classi. Appartengono entrambi al namespace System.Diagnostics.

DebuggerHiddenAttribute

L’attributo DebuggerHidden permette di “nascondere” un costruttore, un metodo o una proprietà. Decorando un membro dei precedenti con questo attributo facciamo si che quando si esegue il debug non si possa eseguire uno step-into all’interno del metodo o fermarsi in un breakpoint interno al metodo stesso.

Un esempio di utilizzo dell’attributo è il seguente:

  1. Public Class Class1
  2.  
  3.     Public Function NotHiddenMethod() As Boolean
  4.         Return True
  5.     End Function
  6.  
  7.     <Diagnostics.DebuggerHidden()> _
  8.     Public Function HiddenMethod() As Boolean
  9.         Return True
  10.     End Function
  11.  
  12. End Class

Di fatto, il metodo HiddenMethod non può essere debuggato né utilizzando lo step-into né inserendo un breakpoint all’interno (per la cronaca l’ambiente di sviluppo permette di inserire il breakpoint ma questo non è attivo).

DebuggerStepThroughAttribute

DebuggerStepThrough funziona in maniera analoga al precedente attributo ma si limita solo a non permettere l’esecuzione dello Step-Into nel metodo e non a disabilitare i breakpoint interni. In più rispetto al precedente attributo, questo può essere applicato anche a livello di classe o struttura in modo da inibire tutti i membri della classe o struttura stessa.

In realtà l’attributo funziona in due differenti modalità in base all’opzione “Enable Just My Code” impostata nelle proprietà di debug del progetto:

clip_image002

Se è abilitata l’opzione Just My Code, l’attributo si comporta esattamente come l’attributo precedente non permettendo neanche i breakpoint interni ai membri decorati.

Se non è abilitata l’opzione Just My Code, invece, il flusso di esecuzione in debug si fermerà su eventuali breakpoint interni ai membri pur non permettendo lo step-into.

Commenti

Post popolari in questo blog

VB for Dummies: La serializzazione – parte 2

Questo post è la continuazione del precedente post sulla serializzazione. In particolare vedremo la serializzazione SOAP e quella JSON.   Serializzazione SOAP La serializzazione SOAP è demandata alla classe SOAPFormatter contenuta nel namespace System.Runtime.Serialization.Formatters.Soap contenuto nella libreria omonima. Il formatter SOAP risale alle primissime versioni del framework e, purtroppo, da un certo punto in poi, pur non essendo stato dichiarato obsoleto, non è stato portato avanti nello sviluppo e non supporta alcuni tipi di dati usatissimi nel mondo .NET quali i generici e i nullable. Per questo motivo, non possiamo serializzare in formato SOAP (utilizzando il SOAPFormatter) la nostra Fattura (vedi post precedente) poichè questa ha una proprietà di tipo List(Of DettagliFattura) (generico).   Serializzazione JSON Il formato di serializzazione JSON (maggiori info qui ) è un formato testuale molto in voga nelle applicazioni AJAX. Si trata di un mod...

Recensione: Windows Runtime via C#

Può sembrare strano che un VB-ista legga un libro su C#, ma come diceva Sun Tzu: “ Se conosci il tuo nemico, conosci te stesso ”. A parte gli scherzi, il libro vale la pena di essere letto a prescindere dal linguaggio .NET con cui si lavora. Oltre  290 pagine dedicate agli aspetti fondamentali dello sviluppo con Windows Runtime per le Windows Store App. I prerequisiti per poter leggere il libro sono la conoscenza di C# e di Visual Studio e gli autori non danno per scontato quasi nulla partendo dai concetti di base quali il type system e i suoi principi (argomento che di solito è saltato a piedi pari da chi si avvicina al mondo WinRT dal framework completo e che, se non compreso, può dare problemi nello sviluppo quotidiano). Tra i concetti che possiamo definire “core”, troviamo anche i capitoli dedicati all’app packaging e al process model, entrambi ben strutturati e chiari. Già solo questi tre capitoli iniziali giustificherebbero, in un certo qual modo, l’acquisto del libro, ...

Alla scoperta del Kinect : questione di profondità

Nei due precedenti post ( link e link ) abbiamo fatto conoscenza con “l’aggeggio” kinect e visto come sia possibile, in maniera molto semplice, gestire lo stream video proveniente dalla camera. In questo post diamo un’occhiata alla capacità che ha il Kinect di fornire frame in cui l’immagine non è la rappresentazione fedele della realtà che ci circonda ma la rappresentazione bidimensionale della distanza degli oggetti dai sensori di profondità. L’aggeggio, infatti, dispone di un sensore di profondità che è in grado di fornirci la distanza dei punti inquadrati da se stesso e, in più, è in grado di dirci a quale “player” fa riferimento ogni singolo pixel. Ma andiamo con ordine. Per abilitare la ricezione del depth stream è necessario: Istanziare la classe Runtime; Agganciare il gestore dell’evento DepthFrameReady; Inizializzare l’istanza della Runtime scegliendo una delle opzioni che abilitano il sensore di profondità; Aprire lo stream dei dati relativi alla pro...