나는 주말에 약간 잔인하게 프로젝트를 2.0 플랫폼으로 업그레이드하기로 결정했습니다. VS2003과 2005가 공존할 수 있기 때문에 문제는 비교적 쉽게 2005 Pro 버전을 설치하고 원본 프로젝트를 열고 업그레이드하는 것입니다. 마법사가 자동으로 나타납니다. 프로젝트에는 7개의 하위 프로젝트가 포함되어 있습니다. 모든 로직과 디스플레이는 백그라운드 프로젝트에서 구현됩니다. 프런트 엔드 웹 프로젝트의 각 파일은 백그라운드 메서드에 대한 호출만 구현하므로 백그라운드 구문에서는 고급 메서드가 사용되지 않습니다. 업그레이드가 매우 원활합니다.
정리하자면, 웹 프로젝트의 프로젝트 파일이 삭제되었습니다. 컴파일 과정에서는 관련되지 않은 두 개의 ASPX 파일도 고려된 것으로 나타났습니다. 컴파일해서 서버에 업로드하고 오류를 보고했습니다. 나중에 새로 컴파일된 프로젝트에는 웹 프로젝트의 Dll이 없지만 서버 디렉토리에는 여전히 남아 있다는 것을 발견했습니다. 그 결과 내부 참조가 엉망이 되었습니다. 이전 웹 프로젝트의 Dll을 삭제하면 괜찮습니다.
그런 다음 게시 모드를 시도할 계획이었습니다. VS2005의 생성 메뉴 항목에서 게시할 디렉터리를 설정했습니다. 옵션은 실제로 웹 디렉터리의 모든 것을 복사하도록 설정되었습니다. 컴파일 과정이 매우 복잡했습니다. 컴파일이 완료된 후 bin 디렉터리에 여러 가지가 생성되었습니다. 이러한 항목을 서버에 복사하면 클린 컴파일이 필요하지 않을 것이라고 생각했습니다. 페이지에 처음 액세스할 때 csc 프로세스가 계속 나타나는 것으로 나타났습니다. 전체 웹사이트를 전환한 후에도 여전히 csc 프로세스가 많이 남아 있었지만 컴파일 프로세스는 이전보다 조금 더 빨라졌습니다.
또 심각한 문제가 발생했는데, 잠시 후 프로그램이 자동으로 다시 시작되는 현상이 발생해 다시 컴파일을 하게 되었는데, 나중에 서버에 w3wp.exe 프로세스에 오류가 발생했다는 오류창이 떴습니다. 그것? 취소를 선택한 후 w3wp.exe가 자동으로 다시 시작되고 새로운 재컴파일이 시작되었습니다. 이 과정이 세 번이나 진행됐고, 너무 무서워서 빨리 버전 1.1로 다시 전환했습니다. 이벤트 뷰어를 살펴본 결과 기본적으로 빈 값이 있는 오류인 처리되지 않은 예외가 많이 발견되었습니다. 이상하게도 1.1에서는 문제가 없었고, 코드도 바뀌지 않았습니다.
나중에 나는 http://www.eggheadcafe.com/articles/20060305.asp 라는 기사를 발견했습니다(중국어로 된 누구도 언급하지 않은 것 같습니다). 2.0의 처리되지 않은 예외 처리는 1.1의 그것과 매우 다릅니다. 다르므로 1.1에서는 페이지 생성에 영향을 주지 않는 한 이를 무시합니다. 그리고 2.0에서는 프로세스가 오류를 보고하게 되어 전체 웹사이트의 운영에 직접적인 영향을 미치게 됩니다. 심각한 문제처럼 들리지만 더 합리적으로 보입니다. 그렇지 않으면 프로그래머는 이 오류를 계속 무시할 것입니다. 그러나 이 문제로 인해 웹 사이트를 전환할 수 없는 문제도 심각한 문제이므로 여전히 원활한 전환 방법이 필요합니다. 위에서 언급했듯이 이 방법은 처리되지 않은 모든 예외를 처리하고 예외 정보를 시스템 이벤트에 기록하기 위해 HttpModule을 직접 작성하는 것이므로 프로그래머가 처리하는 데 도움이 됩니다. 그리고 데모 웹앱을 포함하여 이 HttpModule의 소스 코드와 바이너리 파일 다운로드도 위에 제공됩니다.
오늘 드디어 2.0 배포 전 릴리스의 컴파일 방법을 이해했습니다. VS를 사용하여 웹 사이트를 게시하는 것은 잘못된 것입니다. 수동으로 컴파일하려면 aspnet_compiler.exe를 사용해야 하며 컴파일 프로세스는 웹 사이트의 실제 설정을 기반으로 합니다. 즉, 웹 프로젝트의 내용을 웹 사이트에 업로드하고 IIS에서 웹 사이트의 경로를 설정한 다음 aspnet_compile을 사용하여 로컬로 컴파일해야 합니다. 이 프로세스는 실제로 생성된 dll을 C:에 넣습니다. WindowsMicrosoft.Net의 캐시 디렉터리에 있는 캐시 디렉터리는 사용자가 실제로 페이지에 액세스할 때 csc.exe에서 생성된 캐시 디렉터리와 정확히 동일합니다. 이 단계 후에는 사용자가 두 번 방문할 때 컴파일 작업이 발생하지 않습니다.
너무 피곤해요. 그런데 저는 두 개의 웹사이트가 두 개의 서로 다른 디렉토리를 가리키도록 유지하는 원활한 전환 방법을 생각했습니다. 그 중 하나는 호스트 헤더가 없고 다른 하나는 업데이트를 위한 호스트 헤더가 있습니다. 호스트 헤더로 웹 사이트를 업데이트한 후 aspnet_compiler를 사용하여 컴파일한 다음 두 웹 사이트의 호스트 헤더를 전환하면 새로 방문한 사용자가 새로 컴파일된 웹 사이트로 연결되어 사용자가 지연을 느끼지 않게 됩니다. 다음에 다른 사이트를 업데이트하세요.
http://www.cnblogs.com/unfish/archive/2006/09/10/500230.html