Visual Studio에서 제로 참조 코드 목록 가져 오기


133

Visual Studio 2013에서 특수 코드 (메소드, 속성, 필드, ...)의 참조 수는 Code Lens 로 표시됩니다 . Visual Studio에서 사용되지 않는 (제로 참조) 코드 를 얻고 싶습니다 . 그들을 구할 방법이 있습니까?

아래 참조를 의미합니다.

여기에 이미지 설명을 입력하십시오


7
그는 특정 방법의 참조 수를 0으로 만드는 대신 참조되지 않은 모든 방법의 목록을 원한다고 생각합니다.
Jurgen Camilleri

1
당신이 경우 않는 사용되지 않는 참조를 찾으려면, 당신은 찾을 수 많은 중복 질문을. 그냥 "C #을 사용하지 않는 코드를 찾을 수"에 대한 구글
파나지오티스 Kanavos에게

1
그래 난 모든 사용되지 않는 코드 등 메소드, 속성, 포함 찾으려
니마 Rostami

1
public전체 코드베이스를 검색하지 않으면 a 를 사용하지 않을 수 없습니다 . 그러나 사용하지 않는 내부 및 개인의 경우 적절한 경고가 활성화되어 있으면 Code Analysis에서 경고를 표시합니다.
Matthew Watson

2
몇 년 후, 스크린 샷은 계속해서 오도됩니다.
Sinjai

답변:


184

아마도 당신이 겪고있는 것을 달성하는 가장 쉽고 쉬운 방법은 Visual Studio와 함께 제공되는 코드 분석 도구를 사용하여 죽은 코드와 사용하지 않는 멤버를 직접 찾아가는 것입니다.

이를 위해 새 코드 분석 규칙 세트 파일 (Via File-> New-> File )을 작성 하고 왼쪽 분할 창의 일반 이 선택 되어 있는지 아래로 스크롤하여 Code Analysis Rule Set 를 찾아 파일 이름을 지정한 다음 아래 규칙 선택). 복사 할 수있는 규칙 세트 파일의 내용은 아래를 참조하여 확장명이 .ruleset 인 새 파일에 붙여 넣어 사용하십시오.

규칙 세트 파일이 제공되면 솔루션 탐색기 패널 에서 프로젝트 파일을 마우스 오른쪽 단추로 클릭 하고 특성을 선택할 수 있습니다. 프로젝트 특성 창 에서 왼쪽 패널 의 코드 분석 탭을 클릭 한 후 열기 를 클릭하여 .ruleset 파일의 위치를 ​​찾으십시오. 솔루션 파일의 속성으로 이동하면 (프로젝트 파일이 아닌) 솔루션의 각 프로젝트에 대한 코드 분석 파일을 한 곳에서 ( 코드 분석 설정 아래) 드롭 다운을 사용하여 선택할 수 있습니다. 참고 : 그러나이 속성 창의 드롭 다운에 규칙 세트 파일이 표시 되려면 이전에 규칙 세트 파일을 찾아 봤어야합니다.

그런 다음 간단히 프로젝트 / 솔루션에서 코드 분석을 실행하고 (Via Analyze-> 솔루션에서 코드 분석 실행 -또는 Alt + F11 ), 경고, 참조되지 않은 메소드 또는 사용하지 않는 멤버로 돌아갑니다. 심지어 다른 곳에서는 참조가없는 메소드가 참조하는 메소드를 찾을 수도 있습니다.

그러나 데드 코드에 대한 코드 분석이 잘못을 저지를 수있는 방법 중 하나는 델리게이트를 통해 메소드를 호출하고 리플렉션을 통해 참조를 '숨겨'내는 것입니다.

데드 코드를 감지하는 규칙은 구체적으로 다음과 같습니다.

  • 다른 코드에서 호출되지 않은 개인 메소드 (CA1811)
  • 사용하지 않은 지역 변수 (CA1804)
  • 사용하지 않은 개인 필드 (CA1823)
  • 사용하지 않은 매개 변수 (CA1801)
  • 다른 코드에서 인스턴스화되지 않은 내부 클래스 (CA1812)
  • 비트 OR 제한 스위치의 데드 코드 (C6259)

아래는 위의 단계를 수행하여 확인할 수있는 .ruleset 파일의 내용입니다. 아래 XML을 복사하여 notepad ++에 붙여 넣고 확장자가 .ruleset 인 어딘가에 저장 하고 위의 설명대로 찾아 사용하십시오.

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Dead Code Rules" Description=" " ToolsVersion="12.0">
  <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
    <Rule Id="CA1801" Action="Warning" />
    <Rule Id="CA1804" Action="Warning" />
    <Rule Id="CA1811" Action="Warning" />
    <Rule Id="CA1812" Action="Warning" />
    <Rule Id="CA1823" Action="Warning" />
  </Rules>
  <Rules AnalyzerId="Microsoft.Analyzers.NativeCodeAnalysis" RuleNamespace="Microsoft.Rules.Native">
    <Rule Id="C6259" Action="Warning" />
  </Rules>
</RuleSet>

30
나는 이것이 완전히 질문에 대답한다고 생각하지 않습니다. 주요 차이점은 CodeLens가 PUBLIC 메서드에 전체 솔루션에서 참조가 0이라는 것을 알려줍니다. 이것이 열쇠입니다. FxCop, R # 및 공개되지 않은 모든 항목에 적합합니다.
Scott Wylie

1
@ScottWylie-동의하지 않습니다. 방금 위의 솔루션을 시도했지만 참조되지 않은 공개 메소드에 플래그를 지정하지 않았습니다. CodeLens는 죽은 코드, 참조되지 않은 로컬 항목 및 사용되지 않은 변수를 플래그 지정하는 데 탁월했습니다. 나는 이것이 대부분의 사람들이 타사 도구를 사용하지 않고 원하는 것을 정확하게 얻는다고 생각합니다.
mike

7
@mike 이것을 고려하십시오 : 대량 작업으로 데드 코드를 찾으려면 개인 / 보호 된 멤버는 신경 쓰지 않는 경향이 있습니다. 이는 로컬 문제이기 때문입니다. 예를 들어, 100 개 이상의 프로젝트와 10 개 이상의 솔루션이 포함 된 500k + LoC 프로젝트를 리포지토리 패턴 아키텍처로 마이그레이션하고 있습니다. 구성 요소를 마이그레이션 한 후 삭제할 수있는 이전 인터페이스를 알아야합니다. Eclipse와 같은 일부 IDE에는 정확히 해당 도구가 있습니다. 회색으로 표시된 로컬 메소드는 단순히 내 관심사가 아닙니다. 코드 렌즈가 "0"으로 표시되는 PUBLIC 클래스 / 인터페이스 목록을 원합니다.
Oliver Schimmer

0

https://scottlilly.com/c-code-quality-improvement/remove-unused-classes-properties-and-functions/

"안타깝게도 [Visual Studio Analysis]에서는 사용하지 않는 개인 구성원 만 검색 할 수 있습니다. 이는 코드 분석기가 다른 구성원이 공용 구성원을 사용할 수 있다고 가정하기 때문입니다. 웹 서비스를 통해 API로 공개하는 경우에도 마찬가지입니다. 또는 코드를 라이브러리로 릴리스 할 수 있습니다. ... ReSharper는 유사한 코드 분석 기능을 가지고 있습니다.


0

각 파일을 살펴보고 Ctrl-MO 명령을 사용하여 모든 것을 축소 한 다음 스크롤하여 참조 0을 찾으십시오.


-1

여기에 공개로 표시된 사용하지 않는 클래스를 찾는 데 사용한 수동 방법이 있습니다.

  1. 솔루션에서 하나의 프로젝트에 대해 모든 "공개 클래스"를 검색하고 "개인 클래스"로 바꾸십시오. "public static class"및 / 또는 "public abstract class"를 바꿔야 할 수도 있습니다.
  2. 모든 오류를 찾기 위해 빌드
  3. 빌드의 각 오류에 대해 소스 제어를 사용하여 참조 된 클래스의 파일을 복원하십시오.
  4. 빌드가 성공할 때까지 모든 오류에 대해 반복하십시오.
  5. 복원되지 않은 나머지 파일은 제거 대상이 될 수 있습니다.
  6. (선택 사항) 위의 파일에서 클래스 이름을 바꾸고 오류를 찾기 위해 한 번 더 빌드하십시오.
  7. 마지막으로 제거하려는 클래스 이름을 검색하여 리플렉션 또는 매직 문자열에 사용중인 인스턴스가 없는지 확인하십시오.
  8. 식별 된 사용하지 않는 클래스 파일을 제거하십시오.
  9. 청소하려는 각 솔루션 프로젝트에 대해 반복하십시오.

참고 : 파일 규칙 당 하나의 클래스를 따르지 않으면 더 많은 작업이 필요합니다. 또한 모든 API 서비스 엔드 포인트는 외부 프로젝트에서 사용하지 않는지 확인해야합니다.


14
이것은 실용적이지 않습니다.
돈 롤링

1
그것은 큰 프로젝트에서 저에게 효과적이며 하나의 솔루션입니다. 상황이 더 어려운 곳에서는 상황이 다를 수 있지만 가능한 경우 제공하고자합니다.
Ulfius
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.