ASP.NET 3.5 : 프로덕션 환경에서 debug = true를 사용하면 뚜렷한 이점이 있습니까?

Question

모든 대답은 "아니오"를 가리 킵니다. 그러나 일부 사람들은 디버깅을 사용하도록 설정하는 것이 서버에서 오류가 발생할 때 편리하다고 말합니다. 나는 이것들이 무엇을 의미하는지 확신하지 못한다. 사람들은 실제로 라이브 서버 코드를 디버그합니까? 나는 솔직히 당신이 할 수 있다는 것을 모르고있었습니다. 우리가 작업하는 웹 사이트에서 오류보고를 위해 ELMAH를 사용합니다. 서버 오류가 발생하면 완전한 스택 추적 이메일이 전송됩니다. 오류가 발생한 위치와 방법에 대한 대략적인 아이디어를 얻은 후에 현재 프로덕션 환경에 배포되어 있고 로컬에서 디버깅되는 모든 코드가 포함 된 로컬 솔루션을 엽니 다. 나는 실제로 서버 자체에서 코드를 디버깅하지 않으므로 사람들이 무엇을 의미하는지 확신 할 수 없습니다.

web.config XML을 통합하면서 준비 상태 및 프로덕션 환경의 web.config 파일에 debug = true가 존재한다는 사실을 지금 막 알았 기 때문에이 질문을드립니다. 몇 년 동안이 방법이 있었음에 틀림없지 만 우리가 겪을 이익에 대해 궁금합니다. 디버깅이 켜져 있으면 프로젝트 시작 이후 2 년 이상 사용하도록 설정 한 후 종료하면 중단 될 수있는 디버깅이 필요합니까?

Answer 1

사람들이 말하는 "장점"은 사이트에서 오류가 발생하면 기본 asp.net 오류 페이지에 실제 실패한 코드 줄이 표시된다는 것입니다. debug = false이면 해당 정보가 표시되지 않습니다. 나는 이런 식으로 추천할만한 사람이 대부분 ELMAH와 같은 로깅 프레임 워크에 대해 알지 못한다고 생각합니다. (따라서이 사이트가 없으면 사이트의 오류 원인을 쉽게 찾을 수 없습니다.) 또는 시작 부분에 프로덕션 시스템에 남겨 두었습니다. 프로젝트는 사이트를 설치/테스트하는 동안 프로젝트를 수정 한 다음 나중에 변경하는 것을 잊어 버렸습니다.

그러나 적절한 로깅 프레임 워크를 사용하면 최종 사용자에게 이러한 방식으로 제시하지 않고도 장면 뒤에서 좋은 오류 정보를 얻을 수 있습니다. 사실, 최종 사용자에게 그러한 정보를 표시하고 싶지는 않습니다. 왜냐하면 a) 사용자가 의미하는 것을 알지 못하기 때문입니다. b) 코드의 민감한 부분이 표시되면 보안 문제가 발생할 수 있습니다 (정보 누군가가 취약점을 발견하는 데 도움이 될 수 있음).

Answer 2

전원을 끄면 약간의 성능 향상 효과가 있습니다. ELMAH를 사용하여 옳은 일을하고있는 것 같습니다. 나는 당신이 그것이 생산에서 켜져 있고 싶어하는 좋은 이유를 생각할 수 없다. 희망이 도움이된다.

Answer 3

모든 System.Diagnostic 라이브러리는이 플래그에 의존합니다. 이 함수를 사용하지 않으면 직접 효과를 볼 수 없지만 디버그 함수에서 오는 다른 효과와 메시지를 보려면 Windows 로그 파일을 모니터링해야합니다.

디버그 플래그를 off로 설정하지 않고 성능에 영향을주지 않고 Windows 시스템 로그 파일을 확인하지 않으면 절대로 볼 수없는 작은 문제를 만들면 기능이 Debug.Assert 및 과 같이 계속 활성화됩니다.

우리 라이브러리에서는 assert가 가득차 있기 때문에 디버그 플래그가 중요합니다.

또한 디버그 플래그를 on으로 설정하면 컴파일러가 성능 최적화에도 영향을 미치지 않습니다.

Answer 4

보기에 따라 장점이나 단점은 debug="true" 일 때 Webresource.axd 유형 파일이 캐시되지 않는다는 것입니다. 매번 최신 파일을 갖는 장점과 매번 최신 파일을 갖는 단점이 있습니다.

이것은 다른 제 3 자 압축/결합 유형 모듈에서 종종 사실입니다. 비 축소 된 자바 스크립트 등을 디버그하기가 쉽기 때문에 디버그가 비활성화 된 후에는 일반적으로 제대로 작동하기 시작합니다.