Prepare o ambiente prático de C#

Resumo do laboratório

[!NOTE] Um projeto compilado e uma suíte de testes executada são evidências diferentes.

Conceitos · Primeira tarefa · Lista de evidências · Redefinir

Objetivos de aprendizagem

• Diferencie um SDK instalado do runtime de destino necessário ao projeto.
• Compile um projeto copiado sem tocar em outros workspaces.
• Verifique a descoberta de testes em vez de presumir que compilar é testar.

Antes de começar

Leia configuração da unidade de trabalho e limites de recursos. As fixtures C# integradas têm .NET 10 como destino. C# Dev Kit é útil para a descoberta de testes no editor; compilações e testes pela linha de comando continuam sendo a linha de base reproduzível.

Conceitos e casos de uso

dotnet build compila um projeto. dotnet test descobre e executa seus testes. dotnet run inicia a aplicação e pode depender do diretório de trabalho atual. Um SDK mais novo, por si só, não significa que todos os runtimes mais antigos estejam instalados.

Cenário do exercício

Prepare a fixture da biblioteca para investigação, não um novo modelo de console ou uma alteração de configuração global.

Tarefa 1 - Verifique as ferramentas selecionadas

1. Inspecione o runtime exigido pelo .csproj da fixture selecionada.
2. Execute dotnet --list-sdks e dotnet --list-runtimes.
3. Se o runtime necessário estiver ausente, use a forma de instalação aprovada pela sua organização ou o Dev Container do repositório. Não instale todos os SDKs.
4. Verifique Git e a extensão C# do VS Code se for usar funcionalidades do editor.
5. Para acessar o Copilot, use o laboratório de configuração da conta.

Tarefa 2 - Prepare e compile uma fixture

1. A partir da raiz do currículo:

   node scripts/prepare-hands-on.js --lab 02-csharp --destination /Volumes/T9/Dev/oss/workshop-runs/02-csharp
   

2. Abra somente o diretório impresso.

3. Com as variáveis de cache da unidade de trabalho definidas, execute a partir da raiz dessa cópia:

   dotnet build src/Library.Console/Library.Console.csproj -m:1 -p:UseSharedCompilation=false
   dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false --list-tests
   dotnet test tests/UnitTests/UnitTests.csproj -m:1 -p:UseSharedCompilation=false
   

4. Registre os testes descobertos, os códigos de saída e quaisquer avisos. Uma dependência de feed/rede ausente é um impedimento do ambiente, não evidência de falha em um teste de domínio.

5. Não adicione a mesma fonte NuGet repetidamente nem altere a configuração global de feeds.

Verifique seu trabalho

• O destino do projeto e o runtime instalado são compatíveis.
• O projeto de console compila e o projeto de teste descobre testes reais.
• A saída dos testes é registrada separadamente da saída da compilação.
• Caches e arquivos gerados permanecem na unidade de trabalho selecionada.

Solução de problemas

Se appSettings.json estiver ausente ao executar a aplicação de console, entre em src/Library.Console na cópia descartável antes de executá-la. Se os testes não aparecerem no editor, selecione/compile o projeto de teste e atualize a descoberta; não confunda “zero testes” com sucesso.

Prática independente

Explique por que --no-restore é apropriado após uma restauração bem-sucedida, mas não em um checkout novo. Demonstre a diferença sem instalar um novo framework de testes.

Restauração

Feche a janela da fixture. Mantenha os SDKs compartilhados intactos. Remova somente a cópia descartável inspecionada se não houver evidências ou alterações a preservar.

Referências oficiais

• Visão geral da CLI do .NET
• Testes C# no VS Code
• C# Dev Kit