이 제품은 ASP.Net 웹 응용 프로그램입니다. 현재 Visual Studio에서 웹 사이트 프로젝트를 사용하고 있지만 상당 기간 웹 응용 프로그램 프로젝트를 사용하고 있습니다. 현재 배포 프로세스를 개선 할 수 있도록 조사 중입니다.웹 응용 프로그램 구조 및 배포
서로 다른 클라이언트간에 공유되는 기본 웹 사이트가 있습니다. 그런 다음 클라이언트 웹 사이트 프로젝트에서 클라이언트 관련 기능으로 확장합니다. 클라이언트 프로젝트는 기본을 확장하므로 내용에 의존합니다. 전체 제품을 빌드하려면 먼저 기본 웹 사이트를 배포 한 다음 클라이언트 프로젝트의 컨텐츠로 오버레이합니다.
Visual Studio에서 웹 응용 프로그램 프로젝트로 변환하는 과정에서 기본 프로젝트를 만든 다음 클라이언트 프로젝트를 만들고 기본 참조를 설정할 수 있기를 기대했습니다. 이 구조는 정상적으로 작동하지만 MSDeploy를 사용하여 클라이언트 프로젝트에서 응용 프로그램을 배포하려고하면 기본 웹 사이트의 dll 만 게시됩니다. 컴파일 된 코드를 참조하는 것이 유용하지만 이미지, js 페이지, htm 등과 같이 클라이언트 응용 프로그램이 작동하는 데 필요한 소스가 여전히 있습니다. 기본 웹 사이트의 컴파일 된 코드 이상이 필요합니다.
모든 말했다되는 것을 여기 몇 가지 옵션을 생각할 수 있습니다
- 2 단계 배포를 계속합니다. 먼저 기본 웹 사이트를 만든 다음 클라이언트 웹 사이트에서 전체 제품을 만듭니다.
- 기본 프로젝트에서 필요한 소스 파일을 복사하도록 배포 프로세스를 수정하십시오.
- 이 기본 클라이언트 관계를 다른 방식으로 지원하도록 모델을 다시 설계하십시오. 이것이 어떻게 작동할지는 확실치 않으며, 실행 가능한 옵션이 가장 적을 것입니다.
- ??
다른 옵션이 있습니까? 프로젝트를 설정하는 방식에 문제가 있습니까? 웹 응용 프로그램이 컴파일 된 코드 공유 이외의 다른 웹 응용 프로그램을 참조하도록 만드는 데 더 많은 것이 있습니까? 그렇다면 공유 클래스 라이브러리를 사용하지 않는 이유는 무엇입니까? 아니면 MS 배포 프로세스에서 뭔가가 누락 되었습니까?
나는 뭔가를 놓치고있는 것처럼 느껴진다. 나는 웹 애플리케이션을위한 우리 모델이 너무 독특하다고 생각하지 않는다.
업데이트 : 이중 배포 프로세스는 작동하지만 약간의 복잡함을 느낍니다. 다른 입력?
예, 모델이 비정상적입니다. 그러나 어떤 경우에도 웹 사이트 "프로젝트"에서 도망 간다. 그들은 독특하고 좋은 방법이 아닙니다. –
예. 우리는 잠시 웹 사이트 프로젝트가 .. 음, 여러 가지 방법으로 "특별"하다는 것을 알고 있습니다. 그것의 다만 단단한 무언가를 고치는 시간에 단단한. 우리의 구조가 너무 독특해서? 또 다른 옵션은 모든 프로젝트에 애플리케이션의 전체 소스를 포함시키고 일종의 소스 브랜칭을 설정하는 것입니다. 우리는 이전에 그렇게 했으므로 변화를 유지하기가 매우 어려워졌습니다. – yourbuddypal
이전에이 시나리오에서는 분기를 사용하지 않았지만 FYI에서는 TFS 2010의 분기가 과거보다 훨씬 사용하기 쉽습니다. 보세요. 또한 응용 프로그램의 클라이언트 관련 부분을 공통 부분과 조심스럽게 분리하여 격리하는 것이 좋습니다. 앱 내에서 특정 확장 성과 커스터마이징 포인트를 생성하십시오. 그러면이를 가장 효과적으로 배포하는 방법을 더 쉽게 알 수 있습니다. MSDEPLOY로 즐길 수있는 재미있는 트릭이 있습니다. http : //www.amazon을 참조하십시오.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248 –