우리 회사의 다른 개발자 중 한 명이 .NET 2.0 웹 사이트를 작성했습니다. 그는 "inetpub \ AppName"(IIS 공유) 내부의 모든 것을 솔루션, 프로젝트, 소스 등 모든 것을 저장합니다. 나는 전에 이것을 한 번도 본 적이 없다. 사실 나는 웹 사이트가 브라우저에로드되는 것에 다소 놀랐습니다. 이 말을하는 것의 단점이 있습니까? Visual Studio 2010 프로젝트 폴더에 솔루션을 저장 한 다음 웹 사이트를 inetpub (보안, 속도 등)에 게시하면됩니까? 또한, 이것은 왜 작동합니까?inetpub에 솔루션을 저장해도 괜찮습니까?
사이트가 즉시 컴파일되기 때문에 작동합니다. 이는 성능 관점에서 (후기 컴파일이므로) 좋지 않으며 보안 관점에서 나쁘다. (코드가 필요 이상으로 노출된다.)
ASP.NET 먼저 사용자의 요청에 따라 웹 사이트를 컴파일하기 때문에
MSDN에서, 당신은 단순히 프로덕션 웹 서버에 응용 프로그램의 소스 코드를 복사 할 수 있습니다. 그러나 ASP.NET은 웹 사이트를 배포하기 전에 컴파일하거나 배포 한 후 사용자가 웹 사이트를 요청하기 전에 컴파일 할 수있는 미리 컴파일 옵션도 제공합니다. 미리 컴파일은 몇 가지 장점을 이
좋은 답변입니다. 정확히 내가 알 필요가있는 것. –
실제로 작동하지 않아야하는 이유는 없지만 일반적으로 나쁜 생각으로 간주됩니다. 그는 공유 사이트에서 직접 개발하고 있습니까? 그것은 무섭다. 그가 아니더라도 공유 사이트에 많은 파일을 보관해야합니다. 서버가이를 반환하지 않도록 구성 될 수 있지만 서버에 의존하지 않아야합니다.
로컬 컴퓨터에서도 마찬가지입니다. 그것보다 다른 이유가 없다면 출판 된 사이트를 제대로 모방하지 못하고 물건을 시험하기에 나쁜 장소가됩니다.
나는 나쁜 습관이라고 말하고 싶습니다. 전체 코드는 웹 서버에 있습니다. 서버가 해킹되면 코드는 공짜로 제공됩니다.
을 참조하십시오. 나쁜 습관에 동의하지만 컴파일 된 DLL이 소스를 숨기지 않는다는 오해는 없습니다. 디 컴파일러는 .NET DLL에서 소스를 쉽게 추출 할 수 있습니다. – itchi
규칙에 의해 Inetpub 폴더-은 그냥 기본 웹 서버 루트에 대한 특별한 아무것도 없습니다. ASPX 페이지가 솔루션 (프로젝트 파일의 XML에서만 참조되는)의 일부인 경우 IIS가 ASPX 페이지를 표시하지 못하게 할 수는 없습니다. Visual Studio Projects 폴더의 IIS 프로젝트 디렉터리를 가리킬 수도 있습니다.
C에 사용자 데이터 저장 : 일반적으로 나쁜 습관 (특히 프로그래머의 경우)입니다. 우리 중 대부분은 자주 백업되는 사용자 데이터 만 포함하거나 다른 서버의 소스 리포지토리를 사용하는 데이터 파티션이 있습니다.
안전한 LAN을 사용 중이며 스스로 개발하는 경우 InetPub에 솔루션을 배치하는 데 실제로 문제가 없습니다. 그러나 동일한 IIS를 사용하여 전 세계에 퍼블리시한다면 나는 권하지 않습니다. 당신은 귀중한 보석에 누가 갈지 모릅니다.
업데이트 : Vishal Joshi는 내 질문에 더 많은 내용을 담은 훌륭한 기사가 있습니다. Q1에서 http://vishaljoshi.blogspot.com/2009/08/web-application-project-vs-web-site.html –