ASP.NET 웹 응용 프로그램 .dll 파일을 내 웹 사이트의/bin/디렉터리에 업로드 할 때 릴리스 빌드를 다시 컴파일하는 대신 디버그 버전을 사용하는 데는 단점이 있습니다.ASP.NET 웹 사이트 DLL : 디버그 버전과 릴리스 버전
예를 들어 웹 사이트에서 로컬로 작업하는 동안 빌드 구성이 디버그로 설정됩니다. 상황이 좋게 보이면 웹 사이트/webapp에 최신 .dll을 업로드합니다. 대신 그 시점에서 빌드 구성을 릴리스로 전환 한 다음 컴파일하고 해당 버전의 .dll을 서버에 업로드해야합니까?
나는이 질문이 중복되지 않기를 바랍니다. 주제에 비슷한 단어가있는 다른 질문을 많이 읽었지 만 제 질문에 직접적으로 관련된 것을 찾지 못했습니다.
감사, 그것의 많은 개인의 필요가 무엇인지에 따라 달라집니다
디버그 어셈블리를 사용하면 더 많은 메모리를 차지하지만 성능은 약간 향상되지만 대개 그렇게 중요하지는 않습니다. 릴리스 빌드가 실제로 "릴리스"일 때만 배포해야합니다. 야생에서 예기치 않은 동작이 계속 발생할 것으로 예상되는 경우 디버그 어셈블리를 사용하는 것이 좋으므로 처리되지 않은 예외에서 더 유용한 정보를 얻을 수 있습니다. 실제 성능 "gotcha"가 debug="true" 인 web.config에 있습니다.
아담. 일반적으로 사람들은 성능상의 이유로 디버그 빌드를 프로덕션 환경에 배치하는 것을 싫어합니다. 방출 된 디버그 코드는 분명히 최적화되지 않았으며 코드 실행 속도를 늦출 수있는 디버그 기호가 포함되어 있습니다.
반면에 코드가 예외를 throw 할 때 줄 번호 등을 쉽게 볼 수 있도록하기 위해 디버그 빌드를 프로덕션 환경에 두는 정책이있는 곳에서 작업했습니다. 나는이 위치에 동의한다는 말은 아니지만 사람들이 그것을하는 것을 보았다.
Scott Hanselman은 디버그와 릴리스의 하이브리드 버전을 수행하는 데 좋은 포스트를 가지고 있습니다.이 디버그 및 릴리스를 사용하면 두 세계 모두에서 최고의 이점을 얻을 수 있습니다. here.
릴리스 빌드와 디버그 빌드간에 성능에 큰 차이가있는 응용 프로그램은 거의 없습니다. 중소 규모의 응용 프로그램을 실행 중이며 잡히지 않은 버그가 있다고 생각되면 디버그 빌드를 사용하십시오.
Jinx :-) 같은 생각을 나중에 초 게시했습니다. –
웹 사이트가 적은 경우 디버그 어셈블리의 성능이 저하 될 수 있습니다. 볼륨이 크다면 코드를 로깅/인스트루먼트하는 다른 방법을 찾아보십시오.
대규모 웹 사이트에서는 광범위한 스트레스 및 부하 테스트를 수행하여 응용 프로그램을 제작하기 전에 중단하기가 매우 어렵습니다. 디버그 어셈블리를 사용하여 테스트의 첫 번째 단계를 수행합니다 (아마 물건을 깰 것이므로 어디에서 볼 수 있는지 쉽게 알 수 있습니다). 그런 다음 릴리스 어셈블리를 반복하여 디버그 어셈블리와 동일한 방식으로 동작하는지 확인합니다.
웹 응용 프로그램 프로젝트 (파일 -> 새 프로젝트로 작성)인지 또는 웹 사이트 (파일 -> 새 웹 사이트로 작성)인지 여부를 지정하십시오. –