2013-01-09 17 views
5

Ho una classe C# che ha troppi codici in ingresso e io voglio refactor. Quello che vorrei fare è iniziare con tutti gli public methods e creare uno tree per ognuno di essi, mostrando quali altri metodi della classe sono chiamati da esso, e poi quali sono chiamati da quello secondario, e così via.Come faccio a trovare i metodi che vengono chiamati da un metodo di classe C# - NON in fase di esecuzione

Ciò mi consentirà di vedere quale private methods appartiene esclusivamente a uno public method, che sono condivisi e così via.

Nota che NON voglio farlo in fase di esecuzione, voglio essere in grado di guardare una classe, direttamente allo .cs file, o utilizzando la riflessione sul compilato DLL.

So che posso utilizzare il reflection sulla DLL compilata per ottenere i metodi, ma non riesco a trovare alcun modo per scoprire quali metodi sono chiamati con altri metodi nella classe.

Qualche idea? Ancora una volta, questo NON è un problema di runtime, è puramente per costruire un programma di utilità riutilizzabile per aiutare il refactoring di una classe sovradimensionata. Ce ne sono parecchi nella soluzione su cui sto lavorando, quindi il codice dovrebbe essere usato più e più volte.

+0

Il resharper ha questo. Ti mostrerà tutti gli usi di un metodo. – Oded

+3

Fare clic con il tasto destro del mouse sul metodo -> "Visualizza gerarchia chiamate"? –

+2

Se si desidera eseguire il rollover: http://stackoverflow.com/a/5741770/16959 questa è una risposta estremamente ben studiata su questo argomento –

risposta

10

Visual Studio 2010 ha l'azione "Visualizza gerarchia di chiamate" in cui è possibile visualizzare tutti i punti della soluzione in cui è stato richiamato il codice.

Dalla mia esperienza questa analisi statica può essere un po 'carente, per il metodo di esempio potrebbe essere chiamato in modo dinamico utilizzando la riflessione, attraverso Associazione dati, attraverso la Dependency Injection Container, ecc

inoltre, che potrebbe essere argomento po' fuori, e non applicabile nel tuo caso, ma trovo che un buon metodo per trovare il codice morto per il componente sia avere una suite di test di integrazione. Quindi è possibile eseguire la copertura del codice e visualizzare visivamente quali percorsi di codice non vengono mai eseguiti.

+2

+1 per il commento su reflection, DI, ecc. –

+0

Sebastian - grazie per la risposta, ma se leggi la mia risposta a Oded e unicron sopra, vedrai perché questa funzione non è abbastanza potente per quello di cui ho bisogno. Il test è un approccio interessante, ma sarebbe troppo lavoro da fare ora su una classe esistente (e molto grande) e troppo difficile da analizzare per vedere cosa ha chiamato cosa. –

+1

View Call Hierarchy mostra effettivamente una specie di albero doppio - o albero e radici :) In modo che tu possa vedere tutti i metodi che chiamano il metodo dato e tutti i metodi chiamati con il metodo specificato. –

Problemi correlati