Solutions e Projetos - Solutions

Solutions

Embora o Visual Studio suporte modelos alternativos de organização de código (diretórios no sistema de arquivos) ou suporte de websites hospedados no IIS, o principal modelo de organização de código é feito através de Solutions e Projects.

Por padrão, uma solution é criada sempre que um novo projeto é criado, independente do tipo do projeto. Solutions tem um papel organizacional importante, principalmente à medida que a quantidade de código em um software aumenta.

Além dos arquivos de projetos, uma solution também pode ter "pastas simbólicas" que permitem manter organizados itens não compiláveis relevantes para o desenvolvimento, tais como imagens, configurações, planilhas, documentos.

Uma explicação introdutória das seções, configuração e funcionamento de solutions podem ser encontradas no artigo de referência O que são soluções e projetos no Visual Studio?.

Modificações diretas no arquivo .sln

Uma solution é um arquivo texto que pode ser aberto e modificado diretamente com editores de texto. A modificação direta pode ser feita em casos de emergência, uma vez que a modificação inadequada dos identificadores de referência pode inutilizar o arquivo.

O Solution Explorer é o painel para administração visual dos itens numa solução. Pode ser acessado através do Menu File > View > Solution Explorer

A partir da janela do Solution Explorer, é possível a criação de um ou mais painéis do tipo Solution Viewer. É um útil importante à medida que a quantidade de objetos numa Solution se torna maior.

Solutions também permitem algumas habilidades adicionais para o desenvolvimento. Discutiremos de maneira abreviada as opções destacadas na imagem a seguir.

Build Solution e Rebuild Solution

Por padrão, o build de projetos no Visual Studio não é automático, sendo necessário solicitar explicitamente o build ou rebuild.

É possível, através dos comandos "Build Solution" e "Rebuild Solution", executar os builds de todos os projetos que estiverem ativos numa solution. O build será realizado para a configuração de projeto que estiver ativa.

A sequência de execução seguirá a árvore de dependências de projetos, partindo das folhas (projetos sem outras dependências) até o tronco (projetos com dependências). Caso haja oportunidades de build paralelo, o Visual Studio executará. De outra forma, todo o build será sequencial.

Os comandos "build solution" e "rebuild solution" devem ser evitados em solutions com muitos projetos. Neste caso, suas execuções são demoradas e, não raro, em várias situações de ordem prática podem ser convenientemente substituídos pelo comando de Rebuild Project.

A execução do comando "Build" ou "Rebuild" para um projeto individual ou para um grupo de projetos pode ser feita diretamente através do Menu de Contexto.

Clean Solution

De maneira idêntica ao Build e Rebuild para solutions, o comando Clean Solution atua sobre todos os projetos ativos.

Para projetos de código .net, remove - principalmente - os artefatos de compilação intermediários e definitivos gerados durante a compilação de projetos.

De maneira idêntica, também é possível executar a mesma limpeza através do menu de contexto para projetos ou grupos de projetos.

Batch Build

Batch build é um comando que permite realizar o build de projetos fora da configuração ativa da solution (debug, release, outras). É um comando pouco utilizado e de praticidade limitada frente a alternativas mais flexíveis, como configurações de build utilizando scripts.

Em todo caso, é um comando que pode ser utilizado para verificação de build após modificações em configurações de projetos.

Algumas das modificações de configurações mais comuns em projetos, cujos efeitos podem ser validadas com o auxílio do Batch Build:

• Configurações específicas de ambiente e plataforma destino em projeto. [Project > Properties > Build > General]
• Diretivas de compilação condicional. [Project > Properties > Build > General]
• Severidade de warnings e tratamento de warnings como erros. [Project > Properties > Build > Errors and Warnings ]

Configuration Manager

O comando Configuration Manager permite tanto a criação de configurações de build quanto a definição de uma configuração ativa. Por padrão, o Visual Studio inicia qualquer nova solution com as configurações "Debug" e plataforma "Any CPU".

A criação de novas configurações, diferentes dos esquemas normalmente oferecidos pelo Visual Studio, é uma tarefa simples e pode ser feita por cópia de uma configuração base.

A efetiva utilidade e o refinamento de cada nova configuração criada, por outro lado, é tarefa complexa e deve ser feito apenas em casos de necessidades específicas. Perceba também que uma configuração de solution é abrangente e tem efeitos sobre todos os projetos e as respectivas dependências de cada projeto que serão incluídos nessa configuração.

Exemplos dessas especificidades são:

• Compilação específicas para plataformas Arm, x64, x86
• Compilação específicas para múltiplas versões do .net

Project Dependencies...

Permite uma inspeção direta das dependências de cada projeto bem como a atribuição e remoção de dependência em cada projeto ativo da solution. Permite também a inspeção da ordem de build dos projetos ativos da solução.

Embora seja possível verificar - projeto a projeto - as suas respectivas dependências, este comando provê uma maneira rápida e centralizada de fazer esta verificação para todos os projetos.

Project Build Order...

A mesma janela de Project Dependencies também permite verificar a ordem em que o build dos projetos da solution está acontecendo. Perceba que esta janela não permite a alteração da sequência de build, sendo apenas um painel de verificação.

A ordem de build, conforme esclarecido mais acima, é influenciada principalmente pelas dependências entre projetos.

Configure Startup Projects

No jargão do Visual Studio, um Startup Project é um projeto que pode ser executado quando o programador acionar o comando de Run ou Executar

Nem todos os projetos numa solution são diretamente executáveis. Projetos do tipo class library são bibliotecas cujas rotinas e estruturas de dados só podem ser acionadas quando utilizados a partir de projetos do tipo Console, Windows Forms, WPF, API ou MVC.

Mesmo na testagem individualizada de class libraries o runtime de testes providencia um host adequado (geralmente um host do tipo console) para que estas bibliotecas possam ser executadas.

Paradoxalmente, o Visual Studio permite que um projeto do tipo class library seja marcado como Startup Project e seja feita uma tentativa de execução.

O resultado será um erro!

Apenas projetos do tipo Console, Windows Forms Application, WPF e Web Application são diretamente executáveis.

Para estes projetos, uma vez escolhido o comando Project > Set As Startup Project, a tecla de atalho F5 tentará executar o projeto escolhido em modo de depuração.

Em alguns cenários de aplicações combinadas, entretanto, a inicialização de uma única aplicação não é suficiente. Alguns cenários em que isto ocorre são os seguintes:

• Um ou mais Console App que dependem uns dos outros (cenário típico de microsserviços).
• Uma Web Application do tipo Aspnet MVC (frontend) depende de uma outra application do tipo Aspnet Web API.
• Teste integrado de Web Application

Nestes e noutros cenários é necessário executar mais de uma aplicação. O Visual Studio oferece a possibilidade de fazer essa múltipla ativação através do comando "Configure Startup Projects", conforme ilustrado abaixo.

Ao configurar múltiplos "Startup Projects" é também possível indicar a ordem em que serão inicializados, bem como se cada um dos aplicativos será executado ou não em modo de depuração.

Load All Projects

Load e unload de projetos é uma habilidade bastante interessante numa solution. O unload de um ou mais projetos retira estes projetos do fluxo de compilação executado quando se solicita uma operação de Build Project, Rebuild Project, Build Solution ou Rebuild Solution.

A descarga de um ou mais projetos é útil quando, na mesma solution, o desenvolvedor estiver trabalhando em outros projetos não relacionados.

A carga e a descarga é interessante porque:

• Elimina as distrações e dificuldades para analisar a lista de erros e warnings durante compilações de muitos projetos.
• Alivia a carga de CPU e memória, principalmente em solutions com muitos projetos.
• Retira o projeto da lista de ações de refatoração.
• Previne modificações acidentais de código em projetos não relacionados

Por outro lado, deve-se ter cuidado com esta prática, porque:

• Projetos descarregados não são modificados em ações de refatoração e portanto, podem parar de compilar quando recarregados.
• Dependências indiretas podem ser modificadas e o projeto parar de compilar.

A operação de Load All Projects, de resto, é bem simples e recarrega todos os projetos que estiverem desativados.

Hide Unloaded Projects

É uma operação de utilidade questionável. Projetos desativados não sobrecarregam a CPU. Também o recurso de agrupar projetos dentro de pastas virtuais de uma solution, em termos práticos, elimina os benefícios desse comando.