A execução do MSBuild falha ao ler SDKToolsPath


130

Olá, estou com um problema ao executar um script NAnt que costumava criar corretamente meu site baseado em .Net 2.0, ao compilar com o VS2008 e suas ferramentas associadas. Atualizei recentemente todos os arquivos de projeto / solução para o VS2010 e agora minha compilação falha com o seguinte erro:

[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): erro MSB3086: A tarefa não pôde encontrar "sgen.exe" usando o S dkToolsPath "" ou o registro chave "SDKs HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft \ Windows \ v7.0A". Verifique se o SdkToolsPath está definido e se a ferramenta existe no local correto do processador correto em SdkToolsPath e se o Microsoft Windows SDK está instalado

Agora, eu tenho versões anteriores (.Net 3.5) do Windows SDK instaladas no servidor de compilação e a estrutura completa do .Net 4.0 está instalada, mas não encontrei uma versão específica do .Net 4.0 do Windows SDK.

Após algumas experimentações e pesquisas, finalmente configurei uma nova variável ambiental "SDKToolsPath" e apontei para a cópia do sgen.exe na minha pasta sdk do Windows 6.0. Isso gerou o mesmo erro, mas percebi que, embora a variável ambiental SDKToolsPath esteja definida (confirmou que eu posso "repetir" na linha de comando e tem o valor esperado), a mensagem de erro parece indicar que está não está sendo lido (observe as aspas vazias).

A maioria das informações que encontrei é específica do .Net 3.5 (ou anterior). Ainda não há muitos 4.0 relacionados por aí. A busca pelo código de erro MSB3086 também não gerou nada útil. Alguma idéia do que possa ser isso?

Scott


Problema relacionado nesta postagem. Eu postei uma resposta lá também. stackoverflow.com/questions/1109955/…
Diego C.

Respostas:


15

Eu tive que aceitar o problema e instalar o VS 2010 em nosso servidor de compilação para corrigir esse problema. Tanto quanto posso ver, não há uma versão 7.0A do Windows SDK disponível em qualquer lugar no MSDN. No entanto, a instalação do VS 2010 parece instalá-lo, criando uma regkey 7.0A e uma pasta 7.0A em Program Files \ Microsoft SDKs \ Windows.


9
Prefiro não instalar o Visual Studio 2010 em um servidor. Prefiro a sugestão de Simmo abaixo de definir o SDK do Windows atual para a v7.1. WindowsSdkVer.exe está localizado em C: \ Arquivos de Programas \ Microsoft SDKs \ Windows \ v7.1 \ Setup (assumindo que ele foi instalado em C: \ Arquivos de Programas).
Philippe

55
Eu descobri que se você instalar apenas o Windows SDK 7.1 e .NET 4.0. O MSBuild não define caminhos adequados para SDK40ToolsPath e SDK35ToolsPath. Para corrigi-lo, tive que alterar algumas entradas no HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0: "SDK40ToolsPath" = "$ (Registro: HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ Microsoft SDKs \\ Windows \\ v7 .1 \\ WinSDK-NetFx40Tools-x86 @ InstallationFolder) "Altere da mesma forma" v7.0A "para" v7.1 "no SDK35ToolsPath e FrameworkSDKRoot.
BlueMonkMN

7
Sheesh - eu mesmo tive o mesmo problema, pesquisei no Google e encontrei minha própria resposta! :) Algo parece ter redefinido minha alteração e acho que preciso aplicá-la manualmente novamente.
BlueMonkMN

3
ARRRGH! Os patches mais recentes do .NET 4.0 (11/08/2011) substituíram essas configurações do Registro!
si618

8
Atualização na minha resposta anterior. Parece que em sistemas operacionais de 64 bits também pode ser necessário atualizar valores semelhantes em HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0, e pode ser necessário instalar o 8.0 SDK ou atualizar os valores em HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 e HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 Fiz todas as etapas acima, exceto a instalação do 8.0 SDK, e não foi possível compilar até eu (como um lote) etapa) incluiu minhas atualizações em todos os nós 4.0 \ 11.0.
BlueMonkMN

227

Não consegui colocar o Visual Studio no servidor de compilação.

O SDK v7.0A é o SDK instalado com o Visual Studio 2010 (A indica que esta é uma versão do VS). Desde então, uma versão mais recente foi lançada. Microsoft Windows SDK para Windows 7 e .NET Framework AKA v7.1 .

Eu instalei isso no meu servidor de compilação. E, por meio do prompt de comando do Windows SDK 7.1 (Iniciar => Todos os Programas => Microsoft Windows SDK 7.1), defino a versão padrão do SDK como 7.1.

Passos:

cd Setup

WindowsSdkVer.exe -version:v7.1

Edite para incluir o comentário de LordHits: não é necessário instalar o SDK inteiro. Instalar apenas as opções ".NET Development / Intellisense e Reference Assemblies" e ".NET Development / Tools" é suficiente.


4
Isso funcionou perfeitamente para mim, combinado com a cópia dos arquivos em C: \ Arquivos de programas \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications da minha máquina VS.
dnolan

1
Eu estava enfrentando o mesmo problema que o autor original e esta resposta resolveu o problema! Não precisei instalar o Visual Studio 2010 na minha máquina Build.
SolutionYogi

37
Além disso, apenas para esclarecer, não é necessário instalar o SDK inteiro. Instalar apenas as opções ".NET Development / Intellisense e Reference Assemblies" e ".NET Development / Tools" é suficiente. Isso e copiar os arquivos do comentário de dnolan.
LordHits

Obrigado por esta solução, funcionou perfeitamente para mim em nosso servidor de compilação! Para sua informação, para qualquer pessoa que esteja se perguntando, o servidor de compilação é o Windows Server 2008 x64.
Adam Weber

Muito obrigado por esta resposta; correu para o mesmo problema no trabalho com isso também.
Abe

20

Basta passar o parâmetro GenerateSerializationAssemblies com o valor Off para seu MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off

7
msbuild.exe / p: GenerateSerializationAssemblies = Off
Daniel

2
Ou defina "Gerar montagem de serialização: Desativado" na guia Compilar das propriedades do projeto do serviço da web.
samneric 21/03

6
O que isso faz exatamente?
esmagar

1
GOTCHA: Se você desativá-lo na guia de compilação, faça isso para a configuração de compilação relevante (DropDown na parte superior da guia Compilação) no meu caso, era apenas o servidor de compilação com o problema, então tive que altere isso na configuração 'Release'.
Myster

14
Eu amo mudar aleatoriamente as bandeiras de construção, sem nenhuma pista do que elas realmente fazem.
AaronLS

14

Eu passo manualmente as variáveis ​​para o MSBuild no servidor de compilação.

msbuild.exe MyProject.csproj "/p:TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" "/p:AspnetMergePath=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools"

1
Foi o que acabei fazendo para um SDK do Windows 10 em um servidor sem o Visual Studio e as Ferramentas de Compilação 2019. Nenhuma das outras soluções pareceu ajudar, e essa fez o truque de maneira limpa.
Nicolás Fantone

8

Encontrei um problema semelhante recentemente no nosso servidor de compilação.

Copiei a pasta 7.0A (C: \ Arquivos de programas \ Microsoft SDKs \ Windows \ 7.0A) do meu computador (que possui o VS2010 instalado) para o servidor de compilação no mesmo local.

Após criar a seguinte chave do Registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A. Defina InstallationFolder como C: \ Arquivos de Programas \ Microsoft SDKs \ Windows \ 7.0A.

Você também pode fazer referência ao registro em sua máquina com o VS2010 já instalado, se estiver confuso sobre o que fazer com o registro no servidor de compilação.


Para mim, a resposta do Simmo não funcionou - esse hack do registro funcionou (Win 2K3 SP2).
precisa saber é o seguinte

7

Corri para o mesmo erro, mas em uma situação diferente: usando o VS 2010 Express e tentando usar a resposta do Simmo para definir explicitamente a versão do SDK - no entanto, o WindowsSdkVer.exe (ferramenta de configuração de versão) parece não ter como alvo o Express (compreensível, pois é limitado )

Estou usando o VS 2010 Express no Win 7 Prof. e ele sempre deseja usar a v7.0A do Win SDK (que não possui todos os exes necessários) e não importa qual versão eu defini explicitamente como atual usando WindowsSdkVer.exe (Ele continua relatando que define a versão atual do SDK, mas para o VS 2008, embora eu só tenha o 2010 Ex instalado.)

Portanto, minha solução alternativa mais barata foi instalar o v7.0 WIN SDK (ou outra versão como v7.1) e renomear sua pasta do sistema de arquivos para v7.0A - basicamente eu menti para o VS 2010 Express, mas agora funciona!


5

Um de seus projetos usa o sgen.exe (Server Generator) para gerar serviço da web. você precisa instalar SDKs para criar o servidor ou remover referências de serviço da Web do projeto.


1
Ou defina "Gerar montagem de serialização: Desativado" na guia Compilar das propriedades do projeto do serviço da web.
samneric 21/03

1
GOTCHA: Se você desativá-lo na guia de compilação, faça isso para a configuração de compilação relevante (DropDown na parte superior da guia Compilação) no meu caso, era apenas o servidor de compilação com o problema, então tive que altere isso na configuração 'Release'.
Myster

4

Eu suspeito que o arquivo de destinos está substituindo o caminho das ferramentas, dei uma olhada rápida nesse arquivo e define o SDKToolsPath como $ TargetFrameworkSDKToolsDirectory sob alguns dos destinos existentes. Não acho que você precise configurá-los no ambiente, mas eles podem precisar ser corrigidos nos arquivos do projeto.

Observe que, de acordo com esta página http://nant.sourceforge.net/, o Nant não suporta .Net 4.0, este poderia ser o problema real?

Desculpe, eu sei que isso realmente não responde à sua pergunta :(


Correto, o NAnt ainda não suporta os formatos de arquivo de projeto / solução para o VS2010, e é por isso que estou ligando para o MSBuild para a etapa de compilação real. Irá verificar o arquivo de destinos.
Scott Mayfield

4

Eu tive o mesmo problema em uma nova máquina Windows 10. Minha configuração:

  • Windows 10
  • Visual Studio 2015 instalado
  • SDK do Windows 10

Mas não consegui criar projetos .NET 4.0:

O nome do arquivo "AL.exe" com o SdkToolsPath-Wert "" ou "Registrador de arquivo de registro" HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Solução: Depois de tentar (e falhar) instalar o Windows 7 SDK (porque isso também inclui o .NET 4.0 SDK), eu precisava instalar o Windows 8 SDK e verificar se o ".NET Framework 4.5 SDK" está instalado.

É uma loucura ... mas funcionou.


Isso exatamente me ajudou no Windows 10 também.
bourbert

3

Você não tem o SDK versão 7.0A instalado? Esse é um problema que você precisará corrigir. Consulte os arquivos de log de instalação do VS2010 para ver o que deu errado. O SDK deve estar presente em c: \ arquivos de programas \ microsoft sdks \ windows \ 7.0a e a chave do Registro listada também deve estar presente. A execução com a versão 6.0a do sgen.exe não está bem, é obrigatório o uso do compilador errado.


1
Lembre-se, este é um servidor de compilação, portanto, instalar o ambiente completo do VS2010 não foi minha primeira escolha. Eu era incapaz de encontrar qualquer download disponível do 7.0a Windows SDK
Scott Mayfield

3
Eu não vejo o problema. Executar uma compilação em uma máquina cuja configuração não corresponde às máquinas de desenvolvimento, é um problema que o desgastará rapidamente.
Hans Passant

3

Defina em Sdk40ToolsPathvez de SdkToolsPathespecificar um local diferente do diretório de instalação.

Eu encontrei um problema semelhante com o AL.exe porque havia copiado as ferramentas na máquina de compilação em vez de instalar o SDK, portanto, as chaves de registro normais estavam ausentes. Fiz uma compilação com saída de diagnóstico (/ verbosity: diagnostic) e notei que havia vários caminhos de ferramentas do SDK definidos: Sdk40ToolsPath, Sdk35ToolsPath e SdkToolsPath. Definir Sdk40ToolsPath para apontar para a pasta bin da versão apropriada do SDK resolveu o problema para mim.


Onde você configurou o Sdk40ToolsPath?
precisa saber é o seguinte

Eu diria que ele precisa ser adicionado ao caminho do ambiente. No entanto, não funcionou para mim.
Timothy Lee Russell

Desculpe, isso foi há tanto tempo que esqueci os detalhes, mas acho que era uma variável de ambiente ou definida no arquivo de projeto do MSBuild. Observe também que a pergunta original está relacionada ao .NET Framework 4.0 / VS2010, mas variáveis ​​diferentes podem ser necessárias para versões posteriores da estrutura.
7287 IanS

2

Eu concordo com a resposta de IanS. Não é necessário instalar o novo SDK. Apenas verifique se os valores da chave do Registro SDK35ToolsPath e SDK40ToolPath for MSBuild estão apontando para corrigir os valores da chave do Registro.

No meu caso, meu projeto foi direcionado para o .NET 3.5 e eu tive que definir o SDK35ToolsPath para a chave HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 para $ (Registro: SDKs da Microsoft \ Microsoft \ Windows \ v6.0A \ WinSDKNetFxTools @ InstallationFolder). E tudo funcionou.


2

Temos um winXP build pc e usamos o Visual Build Pro 6 para criar nosso software. como alguns de nossos desenvolvedores usam o VS 2010, os arquivos do projeto agora contêm referência à "ferramenta versão 4.0" e, pelo que posso dizer, isso indica ao Visual Build que ele precisa encontrar um sdk7.x em algum lugar, mesmo que apenas o .NET 3.5 seja compilado . Isso fez com que não localizasse o lc.exe. Eu tentei enganá-lo, apontando todas as macros para o 6.0A SDK que acompanha o VS2008 que está instalado no PC, mas isso não funcionou.

Acabei conseguindo fazer o download e instalar o sdk 7.1. Criei uma chave de registro para 7.0A e apontei o caminho de instalação para o caminho de instalação do 7.1 sdk. agora, felizmente, encontra um "lc.exe" compatível e todo o código é compilado corretamente. Tenho a sensação de que agora também será capaz de compilar o código .NET 4.0, embora o VS2010 não esteja instalado, mas ainda não o tentei.


2

ToolsVersion = "4.0" faz isso por mim no meu projeto MSBuild:

<Project DefaultTargets="Do" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Bem, no meu caso eu usei ToolsVersion = "14.0" para VS 2015 e isso resolveu o problema
AndrewSilver

2

Primeiro, verifique se você já está baixando o dotNetFx40_Full_x86_x64.exe e está instalado (geralmente é vinculado ao Visual Stdio).

Em seguida, defina rapidamente novas variáveis ​​de ambiente em Variáveis ​​do sistema. como abaixo: "TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools" //note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me.


Isso está resolvendo o problema. Apenas uma dica se alguém tiver o mesmo problema que eu. A variável Env precisa ser chamada TargetFrameworkSDKToolsDirectory e não SdkToolsPath !!!
Markus

1

Eu tive esse mesmo problema e instalou o Windows SDK 7.0 e o Windows SDK 7.1, que não corrigiram o problema. A causa do problema para mim foi que a biblioteca de classes incorreta foi criada com o Target Framework do .NET Framework 2.0.

Mudei para o .NET Framework 4.0 e trabalhei localmente e, quando verificado, o servidor de compilação o construiu com sucesso.


1

Eu tive um problema semelhante, notavelmente msbuild falha: MSB3086, MSB3091: "AL.exe", "resgen.exe" não encontrado

Em uma máquina Windows 7 de 64 bits, instalei o .Net framework 4.5.1 e o Windows SDK para Windows 8.1.

Embora as configurações do SDK tenham dito que estava atualizado, provavelmente não estava. Resolvi o problema removendo todas as versões instaladas do SDK e instalando o seguinte, nesta ordem:

http://www.microsoft.com/en-us/download/details.aspx?id=3138

http://www.microsoft.com/en-us/download/details.aspx?id=8279

http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx

http://msdn.microsoft.com/en-us/windows/desktop/aa904949.aspx


1

Resposta curta: No arquivo .csproj, existe uma maneira de especificar o caminho para o sgen.exe, usando o SGenToolPath:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="14.0">
  <PropertyGroup>
    <SGenToolPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</SGenToolPath>
  </PropertyGroup>

Seu caminho pode ser diferente, mas o SGenToolPath é o que você deseja.

Para obter uma lista de outras propriedades comuns do projeto MSBuild, consulte: https://msdn.microsoft.com/en-us/library/bb629394.aspx

Acabamos usando essa configuração do SGenToolPath no arquivo .csproj, em vez de editar os valores do registro no servidor de compilação. A edição dos valores do registro na minha máquina local também funcionou, mas era um pouco mais complicada e não queríamos mexer com o registro no servidor de compilação.

Para o registro: nesse caso, o problema era que os SDK40ToolsPath (s) em HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild estavam apontando para um valor de registro $ (Registro: SDKs para HKY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86 @ InstallationFolder) que não existia. Acabei de substituir isso diretamente pelo caminho real.


1

Também encontrei esse problema ao tentar criar um plug-in usando o Visual Studio 2017 no meu computador no local de trabalho terrivelmente bagunçado. Se você pesquisar na internet "incapaz de encontrar o resgen.exe", poderá encontrar todos esses conselhos, como ' basta usar o regedit para editar o registro do Windows e criar uma nova chave aqui e copiar e colar o conteúdo desta pasta em essa outra pasta, blá blá blá. "

Passei semanas apenas bagunçando meu registro do Windows com o regedit, provavelmente adicionei uma dúzia de subchaves e copiei o ResGen.exe em muitos diretórios diferentes, às vezes colocando-o em uma pasta 'bin', às vezes apenas mantendo-o na pasta principal, etc.

No final, percebi: "Ei, se o Visual Studio fornecesse uma mensagem de erro mais detalhada, nada disso seria um problema". Portanto, para obter mais detalhes sobre o erro, executei o MSBuild.exe diretamente no meu arquivo * .csproj na linha de comando:

 "C:/Windows/Microsoft.NET/Framework/v4.0.3.0319/MSBuild.exe C:/Users/Todd/Plugin.csproj -fl -flp:logfile="C:/Users/Todd/Desktop/error_log.log";verbosity=diagnostic"

Obviamente, você precisará alterar os detalhes do caminho para se adequar à sua situação, mas certifique-se de colocar 1) o caminho completo para o MSBuild.exe 2) o caminho completo para o seu arquivo * .csproj 3) o -fl -flp: logfile = part, que instruirá o MSBuild a criar um arquivo de log de cada etapa executada no processo, 4) o local em que você deseja que o arquivo * .log seja salvo e 5); verbosidade = diagnóstico, que basicamente informa ao MSBuild para incluir toneladas de detalhes no arquivo * .log.

Depois de fazer isso, a compilação falhará como sempre, mas você ficará com um arquivo * .log mostrando exatamente onde o MSBuild procurou o arquivo ResGen.exe. No meu caso, perto da parte inferior do arquivo * .log, encontrei:

Compiling plug-in resources (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.1a\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0a\WinSDK-NetFx40Tools-x86 (Task ID:41)
MSBUILD: error : Failed to locate ResGen.exe and unable to compile plug-in resource file "C:/Users/Todd/PluginResources.resx"

Então, basicamente, o MSBuild procurou em cinco diretórios separados o ResGen.exe e desistiu. Esse é o tipo de detalhe que você simplesmente não consegue obter da mensagem de erro do Visual Studio e resolve o problema: basta usar o regedit para criar uma chave para qualquer um desses cinco locais e colocar o valor "InstallationFolder" na chave , que deve apontar para a pasta na qual o ResGen.exe reside (no meu caso, era "C: \ Arquivos de programas \ SDKs da Microsoft \ Windows \ v10.0A \ bin \ NETFX 4.7.2 Tools").

Se você é especialista em humanidades como eu, sem experiência em computadores, pode ser tentado apenas editar o heck out do Registro do Windows e copiar e colar ResGen.exe em todo o lugar, quando se deparar com um erro como esse (que é claro, más práticas). É melhor seguir o procedimento descrito acima: 1) Execute o MSBuild.exe diretamente no seu arquivo * .csproj para descobrir o local exato em que o MSBuild está procurando o ResGen.exe; em seguida, 2) edite o registro do Windows precisamente para que o MSBuild possa encontrar o ResGen. Exe.


Eu tentei isso, mas por algum motivo não recebo a lista de caminhos que você exibe. Eu encontrei um post semelhante ao seu neste site: community.sdl.com/developers-more/developers/… então eu sei que ele deve funcionar, mas sem sucesso. Qual versão do MSBuild você está usando?
user11809641

Parece que estou usando o MSBuild versão 4.0.30319. Também tenho as versões 3.5, 3.0 e 2.0.50727 instaladas neste computador. Tentei executar essas versões do MSBuild no meu arquivo * .csproj (da mesma maneira descrita acima), mas não funcionou ... nem sequer criou um arquivo * .log. /// Quando você executa o MSBuild no arquivo * .csproj, o computador está produzindo pelo menos um arquivo de log *? Meu entendimento é que existe um arquivo de log, apenas nenhuma informação específica sobre os caminhos que foram pesquisados ​​ao procurar ResGen.exe - isso está correto?
todbott

Parece que tenho a mesma versão do MSBuild (4.0.30319). E sim, você está certo. Estou recebendo um arquivo de log, mas ele não fornece nenhuma informação sobre os caminhos do Registro. Qual dos cinco caminhos que você postou acima acabou usando?
user11809641

Usei o 1º caminho da lista - apenas adicionei um "InstallationFolder" na chave SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86. Além disso, o arquivo * .log é realmente extremamente longo - milhares de linhas, no meu caso. Não consegui encontrar as informações do caminho a olho nu. Acabei abrindo o arquivo * .log no bloco de notas e procurando por "ResGen.exe", que chamou minha atenção para a área pertinente (informações de caminhos).
todbott

1
Super - parabéns! Você se tornou uma das poucas pessoas (algumas centenas, eu acho) que lutaram contra os erros e os mistérios e, na verdade, compilaram com sucesso um plugin para o Trados. Boa sorte com a publicação do seu plugin, até a SDL Appstore!
todbott

1

Corrigi-o passando isso como parâmetro de linha de comando para o msbuild.exe:

Sua milhagem varia de acordo com a versão do SDK que você possui no seu sistema

/p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools

0

Além dos mods de registro, pode ser necessário alterar a versão do .net sdk que suas configurações estão definidas no Visual Studio.

Eu estava com esse problema e decidi verificar as configurações de depuração do projeto.

Projeto => Propriedades da barra de ferramentas => botão Opções de compilação avançada de depuração

O Target Framework (todas as configurações) foi definido como 3.0, que não está no meu sistema.

Alterei isso para 4.0 e tive que reiniciar o projeto e o Visual Studio 2010.

O projeto foi construído sem erros e executado.


Cometi um erro ao localizar o seguinte. Projeto => Propriedades da barra de ferramentas => botão Opções avançadas de compilação da compilação Também criei um novo projeto e o novo projeto .net foi definido como 3.0. Portanto, será necessário alterar a configuração padrão também. Scott A. Tovey
Scott Tovey

Descobri que, quando você cria um projeto, na parte superior da janela há uma lista suspensa de todos os frameworks. Tudo está listado, independentemente de estar instalado ou não. Depois de selecionar uma estrutura e criar um projeto a partir dessa lista, ele permanece o padrão até que você a altere para outra estrutura para um novo projeto. Isso é um pouco imprudente, a lista deve conter apenas estruturas instaladas no sistema.
Scott Tovey

0

Eu tive um problema parecido. Eu tinha feito um projeto usando Visual Studio 2010e obtive o erro acima quando o compilei usando Visual Studio 2012. I simples copiado todo o conteúdo C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0Aem C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0Ae que resolveu o meu problema.


3
Eu gostaria que houvesse uma votação para a pior solução do mundo. Seria isso.
jonypony3

0

Eu apenas tive esse erro com um arquivo .sln que foi criado originalmente no Visual Studio 2010 (e sendo criado pelo Visual Studio 2010 e pelo TFS 2010). Modifiquei o arquivo de solução para NÃO criar um projeto que não deveria ser construído em uma configuração específica e o visual studio alterou o cabeçalho do arquivo de solução de:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010

Para:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 14
VisualStudioVersion = 14.0.24720.0
MinimumVisualStudioVersion = 10.0.40219.1

A configuração da versão original de 2010 corrigiu meu problema. Eu acho que a compatibilidade com versões anteriores no Visual Studio ainda não foi aperfeiçoada.


0

tente usar o "reparo" do visual studio. Funcionou para mim.


0

Wrapper CMD
Eu tentei todas as coisas daqui e ainda mais. Nada me ajudou.

Eu apliquei um wrapper CMD para MSBuild e DevEnv.com.
A idéia principal dentro desse invólucro é criar um ambiente preparado chamando os Prompt de Comando do fornecimento do Visual Studio. E, em seguida, passe os parâmetros de entrada padrão para uma chamada do MSBuild ou DevEnv.com.

De qualquer forma, no meu servidor de compilação agora posso criar projetos de diferentes versões do Visual Studio.

Como usar
Eu tive que substituir chamadas para MSBuild e DevEnv por uma chamada para meus wrappers de arquivos em lote.
E não alterei nenhum parâmetro de entrada. Como um exemplo para minha chamada de wrapper MSBuild:

MsBuild_Wrapper.bat MySolution.sln /target Build /property:Configuration=Release

Solução pronta
Na verdade, tive muito mais problemas com a migração do VS 2010 para o VS 2015. Mas esse foi o primeiro e o mais difícil.
Portanto, minha modesta receita de resgate para um Build Server está aqui. Possivelmente, é difícil entender todo esse estilo de CMD desde o primeiro momento, mas qualquer lógica é óbvia, espero.

Dicas
Existem
MSBuild Command Prompt for Visual Studioe Developer Command Prompt for Visual Studio
eu as uso adequadamente para MSBuild e DevEnv.com. Mas provavelmente o prompt de comando do MSBuild será suficiente.

Para o VS 2015, esses prompts de comando estão aqui C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ . Ou consulte o menu de programas do Windows.

Para passar todos os parâmetros de entrada para o MSBuild ou o DevEnv dentro de um arquivo em lotes que usei CALL MSBuild %*

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.