리플렉터가 왜 필수 유틸리티입니까?

리플렉터를 둘러싼 브로 하하를 읽으면 제품과 그 용도에 대해 생각하게되었습니다. 많은 사람들이이 도구를 필수 도구로 생각합니다.

나는 몇 년 동안 반사경을 사용하지 않았다는 것을 인정해야합니다. .Net API와 내가 사용하는 타사 구성 요소에 대한 설명서가 있습니다. 과거에는 동료가 리플렉터를 공구 벨트에서 꺼낼 때마다 잡초로 향했다는 느낌을 받았습니다.

리플렉터에 대한 모든 열정을 읽으면 여기에 뭔가 빠진 것이 있는지 의문을 갖게됩니다. 왜 Reflector와 같은 것이 왜 필요한 도구라고 생각합니까? 매우 드문 경우이지만 필수 도구로 간주하기에는 충분하지 않습니다. 제발 깨달아주세요

다음은 .NET Reflector가 대답 할 수있는 질문 유형의 완벽한 예 입니다.

또는 SO에 게시하고 Reflector가 설치된 다른 사람이 응답하도록 할 수 있습니다. ;)

저는 두 가지 다른 문제를 해결하기 위해 상당히 정기적으로 (평균 일주일에 1-2 회) 반사기를 사용합니다.

1. 잘 문서화되지 않은 API / 라이브러리 : 여기에 내가 가장 좋아하는 예는 SharePoint입니다. 내가 SharePoint 개발을하는 것으로 알고있는 대부분의 개발자는이 도구를 사용하여 사용 가능한 설명서를 보충합니다. 우리는 그것 없이도 얻을 수 있었습니까? 그러나 다소 어려웠을 경우가 많았습니다.

2. 모호한 오류 디버깅 : 왜 예외가 발생하는지 파악하는 데 유용 할 수 있습니다. 예외가 발생한 위치를 확인할 수 있으면 콜 체인을 추적하여 문제가 무엇인지 파악할 수 있습니다 (라이브러리, 버그 등을 잘못 사용함).

리플렉터는 사용해야하는 써드 파티 어셈블리가 있고 문서화가 잘못되었거나 버그가 있고 코드에서 무슨 일이 일어나고 있는지 알고 싶을 때 필수적입니다.

물론, 당신이해야 할 일은 코드를 난독 화하고 Reflector는 쓸모가 없지만 (또는 마지막으로 확인한 시간이지만) 과거에 많은 시간과 좌절을 구했습니다.

또한 이전 버전 제어 시대에 소스 코드를 잃어 버렸지 만 컴파일 된 코드와 Reflector가 코드를 다시 가져 오는 데 도움이되는 경우가 적어도 한 번 있습니다. 주석, 변수 이름 등이 잘못 되었기 때문에 많은 작업이 필요했지만 도움이되었습니다.

또한 VB.NET과 같은 코드가 있고 C #과 Reflector가 다양한 언어간에 전환하는 방법을 알고 싶을 때가 있습니다.

Reflection.Emit을 사용하여 런타임에 어셈블리를 생성 할 때 Reflector는 생성 된 코드를 시각적으로 확인하는 데 매우 유용한 도구가됩니다.

리플렉터는 설명서가 잘못되었을 때 발견하는 데 도움이됩니다. .NET 1.1에서 CLR의 StringBuilder 설명서에서 버그를 발견했습니다. Length 속성에 대한 설명서 는 다음과 같이 말했습니다.

지정된 길이가 현재 길이보다 큰 경우이 인스턴스의 문자열 값 끝은 공백으로 채워집니다.

이것을 염두에두고 StringBuilder를 사용하려고 시도하고 기괴한 결과를 얻었습니다. 나는 Reflector를 사용하여 문제를 보았다. .NET 2.0 이상의 Length 속성에 대한 설명서 에는 올바른 정보가 있습니다.

지정된 길이가 현재 길이보다 길면 현재 StringBuilder 객체의 문자열 값 끝이 유니 코드 NULL 문자 (U + 0000)로 채워집니다.

예를 들어 MessageBox와 함께 결과 텍스트를 표시하는 경우 큰 차이를 만들 수 있습니다. MessageBox는 첫 번째 null 문자에서 텍스트를 잘라냅니다.

Reflector를 사용하면 이와 같은 내용을 찾아서 CLR이 실제로 동작 하는 방식을 확인할 수 있으며 설명서와 달리 CLR이 실제로 응답하지 않는 질문에 답변 할 수 있습니다.

때로는 라이브러리가 수행하는 작업, 수행 방법, 소스 코드를보고 적절하게 사용하는 것이 더 간단합니다.

다른 경우에는, 나는 단순히 호기심이 많으며 엿보기를 원합니다.

리플렉터를 사용하는 또 다른 일반적인 방법은 프레임 워크 자체가 무언가를 구현하는 방법을 보는 것입니다.

때로는 오래된 프로젝트에서 라이브러리를 사용하고 있으며 소스 코드 나 문서가 없습니다. 이러한 상황에서 반사판은 매우 귀중합니다.

또한 어셈블리를 핫 패치하는 데 사용했습니다. 라이브러리의 내부 비트를 조정하여 Reflector를 사용하여 적절한 지점을 찾은 다음 어셈블리의 IL을 수정해야하는 경우가 몇 가지있었습니다. 이 기능).

나는 그것이 필수적이라고 말하지 않을 것입니다. 그러나 실제로 필요한 경우는 매우 유용합니다.

예를 들어 보자.

최근에 컴파일 타임에 종속 속성의 이름을 모르고 다음에 대한 표현식 트리를 런타임으로 만들 수있는 코드 조각을 만들어야했습니다.

Expression<Func<TMock, TDependency>> expression = (x => x.Dependency);

Moq 프레임 워크를 사용하여 모의 객체를 동적으로 설정하기 위해.

mock.Setup(expression).Returns(dependency);

내가 한 것은 콘크리트 유형을 사용하여 원래 표현식을 컴파일 한 다음 리플렉터를 사용하여 다음 코드를 작성해야한다는 것을 알았습니다.

var argument = Expression.Parameter(typeof(TMock), "x");
var getPropertyExpression = Expression.Property(argument, propertyInfo.Name);
var lambda = Expression.Lambda<Func<TMock, TDependency>>(getPropertyExpression, argument);            
Expression<Func<TMock, TDependency>> expression = lambda;    

시행 착오를 사용하여 이것을 알아낼 수 있었을 것입니다. 그러나 리플렉터가 쉬워졌습니다.

사용 방법을 알고 있다면 문서가 필요하지 않으며 대부분의 API에는 의미있는 문서가 없습니다.