Visual Studio에서 '웹 사이트'와 '프로젝트'의 차이점

Visual Studio에서 '웹 사이트'와 '프로젝트'의 차이점

---

중복 가능성 :
ASP.NET : 웹 사이트 또는 웹 응용 프로그램?

Visual Studio 2008을 실행하고 ' 새 웹 사이트 '-> 'ASP.NET 웹 사이트 '대신 ' 새 프로젝트 '-> 'ASP.NET 웹 응용 프로그램'을 선택하면 얻을 수있는 것과 분명히 차이가 있음을 확인했습니다. '. 예를 들어 '프로젝트'를 선택하면 .dll로 컴파일 할 수 있으며 각 페이지는 * .aspx.designer.cs 코드 숨김 파일을 가져옵니다.

1) 왜이 두 가지 프로젝트 유형이 있습니까?

2) 어떤 것을 선호하십니까?

3) 왜 하나를 선택해야합니까?

4) * .aspx.designer.cs 파일의 거래는 무엇입니까?

---

1) '웹 사이트'모델은 ASP.NET 2.0에서 도입되었으며 '웹 응용 프로그램'모델은 원래 .net 프레임 워크의 프로젝트 유형이었습니다. 둘 다 용도가 다릅니다 (아래 참조).

2) 상황에 따라 다릅니다. 좋은 예는 소프트웨어 제품을 판매하는 경우 자연적으로 깔끔하게 컴파일 된 코드에 적합하기 때문에 '웹 애플리케이션'프로젝트를 사용할 수 있습니다.

3) 위의 개인 취향, 유지 관리 특성을 참조하십시오. 많은 문제를 일으킬 수있는 '웹 사이트'가 할 수있는 흥미로운 것은 웹 사이트가 실행되는 동안 메모장에서 코드 숨김 파일 (일반적으로 * .cs 또는 * .vb)을 임의로 변경하는 것입니다.

4) designer.cs 파일은 자동 생성 된 코드를 저장하는 데 사용됩니다. "이 코드는 도구에 의해 생성되었습니다."

• 차이점을 설명하는 MSDN 문서
• 유사한 stackoverflow 질문

---

그들은 다른 목적을 가지고 있습니다.

웹 사이트는 시간이 지남에 따라 변경 될 가능성이있는 콘텐츠, 즉 페이지 자체가 변경되는 사이트입니다. 실제 프로젝트 파일은 없으며 사이트는 단순히 파일 세트로 배포됩니다.

애플리케이션은 콘텐츠가 애플리케이션 일 뿐인 사이트이며 동적 부분은 주로 데이터베이스와 같은 영구 저장소에 있습니다. 콘텐츠를 검사하는 수단만큼이나 데이터 입력을위한 일련의 양식을 나타낼 가능성이 있기 때문에 더 복잡한 논리를 갖게됩니다. 구성 및 컴파일 된 dll로 배포 된 코드를보다 엄격하게 제어하는 ​​프로젝트 파일이 있습니다.

---

방금 답변을 받았으므로 2의 정의를 복제하지 않겠습니다.

그렇다면 왜 다른 하나를 사용합니까?

웹 사이트를 사용하면 즉시 적용되는 인라인 변경을 수행 할 수있는 PHP 또는 클래식 ASP 사이트처럼 취급 할 수 있습니다.

장점

• 웹 서버에서 바로 사이트를 조정할 수 있습니다.
• 배포는 폴더 복사만큼 간단합니다.

단점

• 라이브 사이트에서 바로 변경하지 않으면 모든 파일을 동기화하는 것을 잊은 변경 관리 문제가 발생할 수 있습니다.
• 확인하는 유일한 방법은 모든 페이지를 수동으로 실행하는 것이므로 최종 사용자에게 런타임 구문 오류가 표시 될 수 있습니다.

웹 응용 프로그램을 사용하면 데스크톱 응용 프로그램처럼 처리 할 수 ​​있습니다. 컴퓨터에 컴파일 된 배포 가능 항목이 하나 있습니다.

장점

• 명확하고 구조화 된 변경 관리. 두 가지 버전의 코드를 실수로 혼합 할 수 없습니다. 이것은 코드를 작성하는 사람과 서버에 파일을 저장하는 책임을 맡고있는 2 명의 사람이 관련된 경우에 중요 할 수 있습니다.

• 컴퓨터에서 컴파일하기 때문에 모든 것이 그 시점에서 구문 검사를받습니다 *

단점

• 배포는 개발 머신에서 폴더를 복사하는 것보다 조금 더 복잡합니다. 그러나 "Publish"명령을 사용하면 웹 서버에 복사해야하는 파일을 컴파일하고 조합하는 프로세스가 크게 단순화됩니다.

• 모든 변경은 컴퓨터에서 수행하고 컴파일해야하며 완전히 새로운 버전을 웹 서버로 보내야합니다 *

* aspx / html 파일은 빌드 옵션에서이 기능을 켜면 구문 만 확인됩니다. 프로젝트로 컴파일되지 않는 한 서버에서 이러한 파일을 편집 할 수도 있습니다.

---

간단한 대답은 다음과 같습니다.

1. 새 웹 사이트-페이지가 요청 될 때 서버에서 컴파일되는 페이지 뒤에 코드를 만듭니다.
2. 새 웹 프로젝트-미리 컴파일 된 페이지를 하나 이상의 어셈블리 (전체 사이트 포함)로 만들고 서버에 배포합니다.

Scenario #1 - If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.

Scenario #2 - if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.

For more information:

Introduction to Web Application Projects

---

3) WebApplication projects are buildable by MSBuild. WebSites are not (without a lot of tweaking). If you use TeamSystem with automated builds then this is the way to go.

---

THe biggest difference that no one has really mentioned (except touched on by Annakata) is that with the model where everything is compiled into a single DLL, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.

With the single page model, you can't do this. You have to get around it by creating "stub" classes in the AppCode directory, and inheriting those in your pages, but even that isn't ideal, and add complexity.

You'll only really come up agaist this stuff if you're trying to develop an intricate dynamic site, where you dynamically load lots of user-controls at run-time based on content. Then, the differences are painfully clear - hence much of our development stalled on ASP 1.1 until we could go back to the same model later.

Nich

---

Speaking from experience with both: "Web Sites" are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes "hotfixes" to specific pages regularly. "Web Applications" are the de facto standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a "hotfix" arises.

---

Sites are the 2003 original .NET way of doing web dev. In my experience they are extremely problematic since lacking a project definition they can't be reused and have issues with modular coding, have issues with TeamSystem integration and namespacing. The one-to-one bind with a domain and lack of real publishing abstraction creates maintenance problems down the line.

The ancient "classic" ASP way of !codebehind is a serious problem because it again impairs code reuse and testing, and the often cited benefits of allowing hot fixes - if ever called upon - is actually a massive signal that you have a failing development process. The ability to hot fix is of course better than not being able to, but it's something you never want to invoke.

You might say that the problems with the web site model were great enough that MS gave us web apps instead. Personally I would never use them for anything beyond demo code... no actually I wouldn't even do that.

---

1. At first there was a Web application project (it behaved similarly to the current Web site project). They changed it to reflect what some users requested. However people wanted the old functionality back so they re-introduced the Web site project which behaves like the original Web application project.

2. I -- and my workplace -- prefer the Web site project

3. We like that the files of the website are the files in the file system (no need to add them manually)

4. No idea

Here's two articles I found about both:

http://damieng.com/blog/2008/02/07/web-site-vs-web-application

http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx

Note: A lot of the issues with Web sites have been resolved with the Web deployment project

Update: Fixed the point 1, Web application was there first

---

If your work needs to leverage oo language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.

The website project (the clue is in the name) is only really good for non-complex 'brochureware' sites (where the pages consist of static content) as opposed to web applications.

---

There is very little difference, and I would highly recommend using the Web Site model.

The main difference is for a website, some files need to be placed in certain directories (code files need to be placed in the 'App_Code' directory), besides that, it's pretty straight forward.

If having compiled code for deployment is important to you, and you want a single DLL (opposed to the several that are created when you do a normal publish for a web site), then you'll want to get this add-on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx

참고URL : https://stackoverflow.com/questions/590501/difference-between-web-site-and-project-in-visual-studio