Web Application vs Web Site Projects in VS2005 for SharePoint Development

Visual Studio 2005 introduced a new web project compilation model, confusing developers migrating from VS2003. Understanding the difference between Web Application Projects and Web Site Projects is critical for SharePoint 2007 development, especially when deploying to the _layouts directory.

The Two Project Models

VS2005 users coming from VS2003 encountered a fundamentally different web project compilation model. The differences affect everything from project creation location to build output.

Web Application Projects

✅ Single assembly: Entire app compiles to one DLL in /bin
✅ Project file: All references and files tracked in .csproj/.vbproj
✅ MSBuild support: Customize pre/post-build events
✅ VS2003 familiar: Same model as previous version
✅ SharePoint compatible: Required for _layouts deployment

Web Site Projects

⚠️ Multiple assemblies: Many DLLs in /bin directory
⚠️ App_Code.dll: Code files compile separately
⚠️ App_Web_*.dll: Each page gets its own assembly
⚠️ Hard to track: Difficult to identify which DLL does what
❌ SharePoint issues: Multiple assemblies problematic for _layouts

Why This Matters for SharePoint 2007

When developing custom applications for SharePoint 2007, one common pattern is creating an ASP.NET application, adding SharePoint references, and publishing to the _layouts directory.

The Single Assembly Requirement

For SharePoint _layouts applications to work correctly, the application must compile to a single assembly. This means you need Web Application Projects, not Web Site Projects.

• Assembly goes in /bin: Single DLL in virtual directory's bin folder
• Pages in _layouts: ASPX files deploy to TEMPLATE/LAYOUTS/YourApp
• SharePoint references: Single assembly simplifies SharePoint API access
• Enterprise Services: COM+ registration requires single assembly

Installation: Adding Web Application Support to VS2005

The Web Application Project model was so important that Microsoft released it as an add-on for VS2005. Here's how to install it:

Step 1: Apply Required Patch

Download and install the prerequisite patch:

Microsoft Download Center → VS2005 SP1 or required hotfix

Step 2: Install Web Application Projects Add-on

Download from MSDN:

ASP.NET 2.0 Web Application Projects → Install the VS2005 extension

Step 3: Verify Installation

After installation, you'll find Web Application Projects in:

File → New → Project → Web → ASP.NET Web Application

(Note: Web Site Projects remain at File → New → Web Site)

Compilation Output Comparison

Web Site Project Output

/bin
  ├── App_Code.dll          ← Classes and code-behind
  ├── App_Web_xxxx.dll      ← Page 1 compiled code
  ├── App_Web_yyyy.dll      ← Page 2 compiled code
  └── App_Web_zzzz.dll      ← Page 3 compiled code

Multiple assemblies make SharePoint deployment complex and error-prone.

Web Application Project Output

/bin
  └── YourProjectName.dll   ← Single assembly with everything

Clean, single assembly perfect for SharePoint _layouts deployment.

SharePoint Deployment Structure

When deploying Web Application Projects to SharePoint, the structure looks like this:

Deployment Paths

C:\Inetpub\wwwroot\wss\VirtualDirectories\YourSiteCollection\
  └── bin\
      └── YourProjectName.dll    ← Assembly goes here

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\
  └── YourProjectName\
      ├── Default.aspx            ← Pages go here
      ├── SomePage.aspx
      └── web.config

Pages in _layouts are accessible via: http://yoursite/_layouts/YourProjectName/Default.aspx

Other Scenarios Requiring Single Assembly

Enterprise Services / COM+: Component registration requires single strongly-named assembly for COM+ console registration
Assembly signing: Strong naming works cleanly with single assembly (multiple assemblies need individual signing)
GAC deployment: Global Assembly Cache deployment simpler with single DLL
Versioning control: Single assembly version number easier to manage than multiple version numbers

Modern Context: .NET Core and Beyond

This Web Application vs Web Site debate is now historical. Modern .NET development has evolved:

• VS2008+: Web Application Projects became the default and recommended model
• ASP.NET MVC/Core: Only supports project-based model (no Web Site model)
• .NET Core/5+: Single project system with SDK-style .csproj files
• Modern SharePoint: SharePoint Framework (SPFx) uses npm packages, not assemblies
• Build systems: MSBuild, dotnet CLI, and modern tooling assume project files

The lesson remains relevant: understand your compilation output and how it affects deployment, especially when integrating with platforms like SharePoint, Kubernetes, or cloud services.

Key Takeaways

1. SharePoint _layouts apps need single assembly - use Web Application Projects
2. Web Site Projects create multiple DLLs - problematic for SharePoint deployment
3. Install Web Application add-on for VS2005 - enables familiar VS2003 model
4. Modern .NET solved this - project-based compilation now standard
5. Understand your build output - critical for any platform integration