Voltando à linha de comando (again)
Caloni, 2026-03-23 computer blogTrabalhar com Windows é um exercício de paciência constante. Junto do Visual Studio um treinamento para ser monge. Cada vez mais penso com carinho em meu aprendizado de algumas ferramentas UNIX para conseguir fazer busca e editar arquivos rapidamente. Talvez hoje com a proximidade e compatibilidade entre os dois SOs seja possível uma convivência produtiva de ferramentas feitas originalmente para terminal. O uso de IA também facilita dar alguns primeiros passos mais rápido, como por exemplo saber lidar com projetos do Visual Studio unicamente pelo terminal.
Com base nisso comecei a migrar meu uso diário do Visual Studio para VS Code apenas com a extensão do Vim e linha de comando. A primeira barreira que encontrei foi usar o msbuild para compilar os projetos C++ e suas dependência. Acontece que aqui no trabalho os projetos possuem ponto no nome e o msbuild simplesmente não suporta-os.
Minha primeira tentativa foi usar o arquivo vcxproj diretamente, mas ele depende de outros vcxprojs que o msbuild não encontra, provavelmente por se tratar de um projeto isolado quando executado assim.
msbuild path\My.Project.Dll.vcxproj cl : command line error D8003: missing source filename [path\My.Project.Lib.vcxproj]
Então resolvi apelar para o nome do projeto. E qual não foi minha surpresa ao descobrir essa incompatibilidade de nomes.
grep My.Project Solution.sln
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "My.Project.Dll",
"path\My.Project.Dll.vcxproj", "{B0191DE5-584F-40BE-8E2B-A8EF5DB2306D}"
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "My.Project.Lib.Lib",
"path\My.Project.Lib.vcxproj", "{3D6A78F0-57D2-4F87-8B51-7E9EBAD3872C}"
msbuild Solution.sln -t:"My.Project.Dll"
MSBuild version 17.14.40+3e7442088 for .NET Framework
MSBUILD : error MSB5016: The name "My.Project.Dll"
contains an invalid character ".". Switch: target
For switch syntax, type "MSBuild -help"
Então outra opção que tentei foi usar a GUID do projeto, o que de acordo com o Chat-GPT "sempre funciona".
msbuild Workplace.Container.sln /t:{B0191DE5-584F-40BE-8E2B-A8EF5DB2306D}
path\AnotherProject.vcxproj : error MSB4057: The target
"{B0191DE5-584F-40BE-8E2B-A8EF5DB2306D}" does not exist in the project.
E por fim tentei especificar no parâmetro /t, só para descobrir que nem lá é permitido usar pontos.
msbuild Solution.sln /t:"path\My.Project.Dll.vcxproj" MSBUILD : error MSB5016: The name "path\My.Project.Dll.vcxproj" contains an invalid character ".".
Por fim, depois de muito suor e tentativas frustradas, encontro a solução: usar o arquivo vcxproj diretamente, mas com o parâmetro /p:BuildProjectReferences=true, que força compilar as dependências do projeto.
msbuild path\My.Project.Dll.vcxproj /p:BuildProjectReferences=true
Importante: para isso funcionar as dependências devem estar em ProjectReference e não só na ordem do .sln. Se seu projeto for antigo pode depender do .sln; aí complica, precisa atualizar as dependências também no ProjectReference.
Este post foi inspirado em saber que (pelo menos atualmente) nem sempre a IA acerta de primeira (ou de segunda, ou de terceira... ou de quinta).