A resposta escolhida sugere que seria possível usar projetos reais em vez de pastas de solução, mas não explica realmente como. Acho que o que estou descrevendo aqui é possivelmente a maneira menos estranha de conseguir isso ... :-P
O problema com arquivos de projeto regulares é que eles eventualmente serão compilados pelo MSBUILD
. E se você quiser um projeto que contenha apenas arquivos não compiláveis, isso será um problema.
Mas, algum tempo atrás, o Visual Studio introduziu um novo tipo de projeto: Projeto Compartilhado (extensão .shproj). Este tipo de projeto não é compilado por padrão, mas apenas quando (e somente se) é referenciado por outro projeto.
Portanto, uma parte do truque aqui é usar projetos compartilhados em vez de pastas de solução . Obviamente, é possível adicionar um projeto compartilhado que nunca é referenciado por nenhum outro projeto, o que significa que podemos evitar o problema apresentado acima.
Então, usando a <None Include="**/*" />
cláusula no arquivo .shproj, podemos fazer com que ele reflita automaticamente quaisquer novos arquivos e / ou subpastas.
Então, basicamente, faça o seguinte:
- Crie uma nova pasta em sua solução.
- Adicione um novo arquivo .shproj na raiz desta nova pasta.
- Faça referência ao novo .shproj em sua solução.
Por exemplo, no meu caso, criei um DockerDev.shproj, para poder agrupar alguns scripts relacionados ao docker que executamos apenas em nossas máquinas de desenvolvimento:
<?xml version="1.0" encoding="utf-8"?>
<!-- DockerDev/DockerDev.shproj -->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<None Include="**/*" />
</ItemGroup>
</Project>
Este arquivo .shproj manterá o controle de qualquer arquivo, em qualquer subpasta desta nova DockerDev
pasta em minha solução.
Pelo que pude ver, esta solução funciona de forma muito semelhante ao que o OP solicitou: funcionará como uma referência não compilável para uma pasta e refletirá automaticamente quaisquer alterações feitas nela.