Pastas - Solução x Projeto | Visual Studio

• Pastas - Solução x Projeto | Visual Studio

---

📁 Pasta na Solução (Solution Folder)

👉 Existe só no Visual Studio 👉 NÃO existe no disco 👉 NÃO afeta namespaces nem build

Características

• É apenas organizacional

• Serve para agrupar projetos

• Não vira pasta física

• Não entra no .csproj

• Não interfere em:

  • compilação
  • runtime
  • publish
  • namespaces

Exemplo de uso

Solução
 ├─ AppHosts
 │   └─ WorkerComputador.AppHost
 ├─ Services
 │   └─ WorkerComputador
 └─ Shared
     └─ WorkerComputador.ServiceDefaults

📌 Muito comum em:

• soluções grandes
• Aspire
• microserviços
• DDD
• monorepos

💡 Se você abrir a pasta da solução no Explorer → essas pastas não existem.

---

📂 Pasta normal no projeto

👉 Existe fisicamente no disco 👉 Entra no build 👉 Afeta namespaces e paths

Características

• Pasta real no sistema de arquivos

• Vira parte do projeto .csproj

• Pode:

  • influenciar namespace
  • influenciar rotas de arquivos
  • ser publicada
  • conter recursos (json, views, etc.)

Exemplo

WorkerComputador
 ├─ Services
 │   └─ Worker.cs
 ├─ Models
 │   └─ Job.cs

Código:

namespace WorkerComputador.Services;

public class Worker { }

📌 Muito usada para:

• organizar código
• separar camadas
• agrupar features

---

⚠️ Diferença CRÍTICA (muita gente erra aqui)

Situação	Pasta da Solução	Pasta no Projeto
Organizar projetos	✅	❌
Organizar código	❌	✅
Afeta namespace	❌	✅
Afeta build	❌	✅
Existe no disco	❌	✅

---

🧠 No seu caso (Aspire)

✔️ Correto

• Solution Folder → organizar:

  • AppHost
  • ServiceDefaults
  • Worker

• Pasta no projeto → organizar:

  • Extensions
  • Infrastructure
  • Services

❌ Erro comum

Criar ServiceDefaults como pasta no projeto achando que é um “módulo” 👉 quando na verdade ele precisa ser outro projeto

---

🧩 Regra de ouro

Se não precisa compilar, é pasta da solução Se precisa virar código, é pasta do projeto

---