Olá pessoal,
Boa tarde!
Neste post vou compartilhar com vocês um problema que eu tive durante o desenvolvimento de algumas rotinas do CLR em C# em um novo ambiente de criei utilizando o VMware, Windows 7 x64 e o Visual Studio 2015 Community Edition.
O problema
O problema ocorre quando eu tento realizar o Build ou publicar o meu assembly no banco de dados. Esse tipo de problema não é exclusivo do CLR e sim do Visual Studio + .NET Framework, afetando desenvolvedores C# também.
A mensagem de erro que ocorre é essa:
Task could not find “sgen.exe” using the SdkToolsPath “” or the registry key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86”. Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
Está bem claro que o que está acontecendo é que o Visual Studio não está conseguindo encontrar o executável sgen.exe. Vamos ententer o motivo.
A solução – Resolvendo o problema
Fazendo uma pesquisa rápida no Google, identifiquei algumas “soluções” apontadas pelos usuários:
- Instalar o Visual Studio 2010: Acho que voltar no tempo e utilizar o Visual Studio 2010 não é legal.. Principalmente porque no VS 2010 eu nem consigo publicar o CLR num banco de dados SQL Server 2014
- Instalar o Windows SDK: Até poderia ser uma possível solução, mas o SDK não está disponível para todas as plataformas, como o Windows Server 2012, por exemplo, então não seria uma solução definitiva.
- Desativar a geração de assembly de serialização: Eu testei essa solução e realmente funciona. O erro não ocorre mais.
Porém, como eu utilizo WebServices e serialização de XML, não é uma opção pra mim, uma vez que se eu não gerar o serializador meu projeto apresentará erros de execução.
Pois bem, como nenhuma delas me pareceu ser uma solução sólida, vamos buscar uma nova alternativa. Analisando mais algumas respostas e publicações, consegui identificar essa forma de resolver definitivamente o problema:
- Abra o RegEdit no seu computador
- Acesse essa chave de registro: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
- Note que a chave SDK40ToolsPath aponta para uma outra chave de registro, que é onde realmente os arquivos ficam localizados. Caso você esteja utilizando o .NET Framework 2.0 ou 3.5 no seu projeto, você deverá olhar para a chave SDK35ToolsPath
- Abra essa chave de registro e veja qual o diretório dos arquivos do SDK
- Agora abra o diretório que está na chave “InstallationFolder” no Windows Explorer. Como era de se esperar, o executável sgen.exe não está nesse diretório.
- Entre na pasta de outro SDK que possua esse arquivo, copie o executável e cole de volta nesta pasta. Acredito que como o executável é stand-alone (não possui dependências), pode ser qualquer versão. Eu sugiro pegar sempre a versão mais recente, respeitando a versão macro da plataforma.
- Após copiar o arquivo, você já pode compilar normalmente seu projeto no Visual Studio.
Obrigado pela visita e até o próximo post.
This explanation is quite complicated to follow and comes to a rather simple workaround, which I had arrived at already.
I have installed Visual Studio 2022 Community presently, and, just to check it out, compiled KeePass2 from sources available at their site.
Among certificate issues, which I could solve, I ended up with one stubborn problem (the one you describe) getting
“Der Befehl “”C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\sgen.exe”” ist entweder falsch geschrieben oder
1> konnte nicht gefunden werden.”
Looking into the given location for the executable, I found it empty except for two subdirectories (C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools and C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8.1 Tools) which both contain copies of the sgen.exe executable. Putting a copy of sgen.exe to the addressed path C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin solved the problem (not compiling) but not the issue (wrong path given for executable).
I am still wondering how this happens in the first place. Un- and reinstalling of the SDKs and Visual Studio 2022 didn’t help any.
Since googling for more information on the problem shows quite a number of postings regarding it, it seems that there is a rather old bug around which nobody, at least not Microsoft, cares to fix.
Me ajudou com problemas na configuração de build no TFS, obrigado amigo!!!