Visual Studio의 "다음을 제외한 모든 경고를 오류로 처리"

Visual Studio에서 "경고를 오류로 처리"옵션을 선택하여 경고가있는 경우 코드가 컴파일되지 않도록 할 수 있습니다. 우리 팀은이 옵션을 사용하지만 경고로 유지하고 싶은 두 가지 경고가 있습니다.

경고를 억제하는 옵션이 있지만 경고로 표시되기를 원하므로 작동하지 않습니다.

우리가 원하는 동작을 얻는 유일한 방법은 "특정 경고"텍스트 상자에 모든 C # 경고 번호의 목록을 입력하는 것 같습니다. 단, 경고로 처리하려는 두 가지를 제외하고는 말입니다.

유지 관리 문제 외에도이 접근 방식의 가장 큰 단점은 몇 가지 경고에 숫자가 없으므로 명시 적으로 참조 할 수 없다는 것입니다. 예 : "이 참조를 확인할 수 없습니다. '데이터 ....'어셈블리를 찾을 수 없습니다."

누구든지 이것을하는 더 나은 방법을 알고 있습니까?

이것이 왜 유용한 지 즉시 알지 못하는 사람들을 위해 설명합니다. 대부분의 경고가 어떻게 작동하는지 생각해보십시오. 그들은 방금 작성한 코드에서 뭔가 약간 벗어났다고 말합니다. 이를 수정하는 데 약 10 초가 걸리며 코드베이스를 깔끔하게 유지합니다.

"사용되지 않음"경고는 이것과 매우 다릅니다. 때때로 그것을 고치는 것은 단지 새로운 메소드 서명을 소비하는 것을 의미합니다. 그러나 전체 클래스가 쓸모없고 수십만 줄의 코드에 흩어져 사용되는 경우 수정하는 데 몇 주 이상 걸릴 수 있습니다. 빌드가 그렇게 오래 손상되는 것을 원하지는 않지만 경고를보고 싶을 것입니다. 이것은 단지 가상의 경우가 아닙니다. 이것은 우리에게 일어났습니다.

리터럴 "#warning"경고도 고유합니다. 나는 종종 원하는 그것을 체크하기 위해,하지만 난 빌드를 중단하고 싶지 않아요.

WarningsNotAsErrors프로젝트 파일에 -tag를 추가 할 수 있습니다 .

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

참고 : 612하고 618있습니다 폐기에 대한 모두 경고의 차이를 알 수 없지만 내가 맡은 프로젝트가 618 경고와 함께 폐기보고하고있다.

/ warnaserror / warnaserror- : 618

또는 더 구체적으로, 귀하의 경우 :

/ warnaserror / warnaserror- : 612,1030,1701,1702

쉼표로 구분 된 목록의 경고를 제외한 모든 경고를 오류로 처리해야합니다.

오류로 처리하지 않는 경고를 계속 표시하려는 이유는 무엇입니까? 나는 이것이 왜 바람직한 지 혼란 스럽습니다-당신이 그들을 고치 든 그렇지 않든.

두 개의 서로 다른 빌드 / 솔루션 파일이 작동합니까-아니면 하나를 복사하는 스크립트가 있으므로 경고 / 경고 수준을 수정하는 것이 적합합니다. 컴파일러의 일부 실행이 삐걱 거리는 것을 원하지만 나머지는 계속 진행하고 싶은 것 같습니다.

따라서 다른 컴파일러 스위치가 좋은 방법 인 것 같습니다. 이 작업은 디버그 또는 릴리스 레이블이 지정된 다른 대상과 경고에 대해 적절하게 레이블이 지정된 다른 대상으로 수행 할 수 있습니다.

경고를 오류로 취급하고 있습니다.

드물게 일부 허용 가능한 경고가 표시되면 (예 : 사용되지 않는 멤버 참조 또는 XML 직렬화 클래스에 대한 문서 누락), #pragma disable을 사용하여 명시 적으로 억제 해야합니다 (선택적으로 깨끗한 코드가없는 이유를 제공 할 수 있음). 주석으로).

이 지시문 이 있으면 질문이있을 때 누가이 경고 위반을 수락 했는지 (버전 제어의 "비난"조치에 의해) 알 수 있습니다.

단순히 "612, 1030, 1701 또는 1702가 아닌 다른 경고가있는 코드를 체크인하는 사람은 화이트 보드로 가서 '허용되지 않는 경고가있는 코드를 다시 체크인하지 않겠습니다. ' "

pragma 경고 (C # 참조)

pragma 경고를 사용하여 특정 경고를 활성화하거나 비활성화 할 수 있습니다.

http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx

나에게 근본적인 문제는 실제로 경고가 명확하지 않은 경우 오류를 오류로 취급하는 것과이를 위반하는 체크인을 허용하는 명백한 정책의 조합 인 것 같습니다. 말했듯이 경고에도 불구하고 계속 작업 할 수 있기를 원합니다. 무시하고 싶은 경고를 몇 가지만 언급했지만, 팀의 다른 누군가가 다른 유형의 경고를 유발하여 고치는 데 똑같이 오래 걸리는 경우 어떻게해야합니까? 그것도 무시하고 싶지 않습니까?

논리적 해결책은 1) 코드가 컴파일되지 않으면 체크인을 허용하지 않거나 (즉, 경고를 생성 한 사용자가 실제로 빌드를 중단했기 때문에이를 수정해야 함을 의미 함) 또는 2) 경고를 경고로 처리하는 것입니다. 두 개의 빌드 구성을 만듭니다. 하나는 경고를 오류로 처리하여 코드에 경고가 없는지 확인하기 위해 정기적으로 실행할 수 있고 다른 하나는 경고로만 처리하고 다른 사람이 경고를 도입 한 경우에도 작업 할 수 있도록합니다.