L'esecuzione di MSBuild non riesce a leggere SDKToolsPath


130

Salve, sto riscontrando un po 'di problemi durante l'esecuzione di uno script NAnt utilizzato per creare correttamente il mio sito Web basato su .Net 2.0, durante la compilazione con VS2008 e gli strumenti associati. Di recente ho aggiornato tutti i file di progetto / soluzione a VS2010 e ora la mia build non riesce con il seguente errore:

[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): errore MSB3086: Impossibile trovare "sgen.exe" utilizzando S dkToolsPath "" o il registro chiave "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A". Assicurarsi che SdkToolsPath sia impostato e che lo strumento esista nella posizione specifica del processore corretta in SdkToolsPath e che sia installato Microsoft Windows SDK

Ora, ho versioni precedenti (.Net 3.5) di Windows SDK installate sul server di compilazione e il framework .Net 4.0 completo è installato, ma non ho incontrato una versione specifica .Net 4.0 di Windows SDK.

Dopo un po 'di sperimentazione e ricerca, ho finalmente installato una nuova variabile ambientale "SDKToolsPath" e l'ho puntato sulla copia di sgen.exe nella mia cartella sdk di Windows 6.0. Ciò ha generato lo stesso errore, ma mi ha fatto notare che anche se la variabile ambientale SDKToolsPath è impostata (confermato che posso "echo" dalla riga di comando e ha il valore previsto), il messaggio di errore sembra indicare che è non essere letto (notare le virgolette vuote).

La maggior parte delle informazioni che ho trovato sono specifiche .Net 3.5 (o precedenti). Non ci sono ancora molti 4.0 correlati. La ricerca del codice di errore MSB3086 non ha generato nulla di utile. Qualche idea di cosa potrebbe essere?

Scott


Problema correlato in questo post. Ho pubblicato una risposta anche lì. stackoverflow.com/questions/1109955/…
Diego C.

Risposte:


15

Ho dovuto mordere il proiettile e installare VS 2010 sul nostro server di build per risolvere questo problema. Per quanto posso vedere, non esiste una versione 7.0A di Windows SDK disponibile ovunque su MSDN. Tuttavia, l'installazione di VS 2010 sembra installarlo, creando una regkey 7.0A e una cartella 7.0A in Programmi \ Microsoft SDKs \ Windows.


9
Preferisco non installare Visual Studio 2010 su un server. Preferisco il suggerimento di Simmo di seguito sull'impostazione dell'attuale Windows SDK su v7.1. WindowsSdkVer.exe si trova in C: \ Programmi \ Microsoft SDKs \ Windows \ v7.1 \ Setup (presupponendo che sia stato installato in C: \ Programmi).
Philippe,

55
Ho scoperto che se si installa solo Windows SDK 7.1 e .NET 4.0. MSBuild non imposta i percorsi corretti per SDK40ToolsPath e SDK35ToolsPath. Per risolvere il problema, ho dovuto modificare alcune voci in 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) "Allo stesso modo, modifica" v7.0A "in" v7.1 "in SDK35ToolsPath e FrameworkSDKRoot.
BlueMonkMN,

7
Sheesh - Ho riscontrato di nuovo lo stesso problema, ho cercato su Google e ho trovato la mia risposta! :) Qualcosa sembra aver ripristinato la mia modifica e suppongo di doverlo applicare di nuovo manualmente.
BlueMonkMN

3
Arrrgh! Le ultime patch .NET 4.0 (2011-08-11) hanno sovrascritto queste impostazioni del registro!
si618,

8
Aggiornamento sulla mia precedente risposta. Sembra che sui sistemi operativi a 64 bit, potrebbe essere necessario aggiornare valori simili in HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 e potrebbe essere necessario installare l'SDK 8.0 o aggiornare i valori in HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 e HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 Ho fatto tutto quanto sopra tranne l'installazione dell'SDK 8.0 e non sono riuscito a compilare fino a quando (come un batch passaggio) includeva i miei aggiornamenti a tutti i nodi 4.0 \ 11.0.
BlueMonkMN il

227

Non potevo affrontare l'inserimento di Visual Studio sul server di compilazione.

SDK v7.0A è l'SDK installato con Visual Studio 2010 (La A indica che si tratta di una versione VS). Da allora è stata rilasciata una versione più recente. Microsoft Windows SDK per Windows 7 e .NET Framework AKA v7.1 .

L'ho installato sul mio server di build. E quindi tramite il prompt dei comandi di Windows SDK 7.1 (Start => Tutti i programmi => Microsoft Windows SDK 7.1), ho impostato la versione predefinita dell'SDK su 7.1.

passi:

cd Setup

WindowsSdkVer.exe -version:v7.1

Modifica per includere il commento di LordHits: non è necessario installare l'intero SDK. È sufficiente installare solo le opzioni "Sviluppo .NET / Intellisense e riferimenti" e "Sviluppo .NET / Strumenti".


4
Questo ha funzionato perfettamente per me, combinato con la copia dei file in C: \ Programmi \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications dalla mia macchina VS.
dnolan,

1
Stavo affrontando lo stesso problema dell'autore originale e questa risposta l'ha risolto! Non ho dovuto installare Visual Studio 2010 sul mio computer Build.
SolutionYogi,

37
Inoltre, solo per chiarire, non è necessario installare l'intero SDK. È sufficiente installare solo le opzioni "Sviluppo .NET / Intellisense e riferimenti" e "Sviluppo .NET / Strumenti". Questo e la copia dei file dal commento di dnolan.
LordHits,

Grazie per questa soluzione, ha funzionato perfettamente per me sul nostro server di build! Cordiali saluti, per chiunque possa essere in dubbio, il server di build è Windows Server 2008 x64.
Adam Weber,

Grazie mille per questa risposta; ho riscontrato lo stesso problema al lavoro anche con questo.
Abe,

20

Passare semplicemente il parametro GenerateSerializationAssemblies con valore Off a MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off

7
msbuild.exe / p: GenerateSerializationAssemblies = Off
Daniel

2
Oppure imposta "Genera assembly di serializzazione: Off" nella scheda Build delle proprietà del progetto del servizio Web.
Samneric,

6
Cosa fa esattamente questo?
schiaccia

1
GOTCHA: Se lo disattivi nella scheda build, assicurati di farlo per la configurazione build pertinente (DropDown nella parte superiore della scheda Build) nel mio caso era solo il server build con il problema, quindi ho dovuto cambiarlo nella configurazione 'Rilascio'.
Myster,

14
Adoro cambiare casualmente i flag di costruzione senza avere idea di cosa facciano realmente.
AaronLS,

14

Passo manualmente le variabili a MSBuild sul server di build.

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
Questo è quello che ho finito per fare un Windows 10 SDK in un server senza Visual Studio e Build Tools 2019. Nessuna delle altre soluzioni sembrava aiutare e questa ha fatto il trucco in modo pulito.
Nicolás Fantone,

8

Ho riscontrato un problema simile proprio di recente sul nostro server di build.

Ho copiato la cartella 7.0A (C: \ Programmi \ Microsoft SDKs \ Windows \ 7.0A) dal mio computer (su cui è installato VS2010) sul server di build nella stessa posizione.

Dopo aver creato la seguente chiave di registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A. Impostare InstallationFolder su C: \ Programmi \ Microsoft SDKs \ Windows \ 7.0A.

Puoi anche fare riferimento al registro sul tuo computer con VS2010 già installato su di esso se sei confuso su cosa fare con il registro sul server di compilazione.


Per me, la risposta di Simmo non ha funzionato - questo hack del registro ha funzionato (Win 2K3 SP2).
Finlandia,

7

Ho riscontrato lo stesso errore ma in una situazione diversa: usare VS 2010 Express e provare a usare la risposta di Simmo per impostare esplicitamente la versione dell'SDK, tuttavia WindowsSdkVer.exe (strumento di impostazione della versione) sembra non scegliere come target Express (comprensibile poiché è limitato ).

Sto usando VS 2010 Express su Win 7 Prof. e vuole sempre usare la v7.0A di Win SDK (che non ha tutti gli ex necessari), e non importa quale versione ho impostato esplicitamente come corrente usando WindowsSdkVer.exe (continua a segnalare che imposta la versione corrente dell'SDK ma per VS 2008 anche se ho installato solo 2010 Ex.)

Quindi la mia soluzione economica è stata quella di installare l'SDK WIN v7.0 (o un'altra versione come la v7.1) e quindi rinominare la sua cartella del file system in v7.0A - praticamente ho mentito a VS 2010 Express ma ora funziona!


5

Uno dei tuoi progetti utilizza sgen.exe (Server Generator) per generare il servizio web. è necessario installare SDK per Build Server o rimuovere i riferimenti del servizio Web dal progetto.


1
Oppure imposta "Genera assembly di serializzazione: Off" nella scheda Build delle proprietà del progetto del servizio Web.
Samneric,

1
GOTCHA: Se lo disattivi nella scheda build, assicurati di farlo per la configurazione build pertinente (DropDown nella parte superiore della scheda Build) nel mio caso era solo il server build con il problema, quindi ho dovuto cambiarlo nella configurazione 'Rilascio'.
Myster,

4

Ho il sospetto che il file target abbia la precedenza sul percorso degli strumenti, ho dato una rapida occhiata a questo file e imposta SDKToolsPath su $ TargetFrameworkSDKToolsDirectory sotto alcune delle destinazioni presenti. Non penso che dovresti averli comunque impostati nell'ambiente, ma potrebbe essere necessario correggerli nei file del tuo progetto.

Si noti che secondo questa pagina http://nant.sourceforge.net/ Nant non supporta .Net 4.0, potrebbe essere questo il vero problema?

Scusa, so che non risponde davvero alla tua domanda :(


Corretto, NAnt non supporta ancora i formati di file di progetto / soluzione per VS2010, motivo per cui sto chiamando MSBuild per l'effettiva fase di compilazione. Verificherà il file target.
Scott Mayfield,

4

Ho avuto lo stesso problema su una macchina Windows 10 nuova di zecca. La mia configurazione:

  • Windows 10
  • Visual Studio 2015 installato
  • SDK di Windows 10

Ma non ho potuto costruire progetti .NET 4.0:

Die Aufgabe konnte "AL.exe" mit SdkToolsPath-Wert "" oder dem Registrierungsschlüssel "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Soluzione: dopo aver tentato (e non riuscito) di installare l'SDK di Windows 7 (poiché include anche l'SDK di .NET 4.0), dovevo installare l'SDK di Windows 8 e assicurarmi che "SDK di .NET Framework 4.5" fosse installato.

È pazzesco ... ma ha funzionato.


Questo mi ha aiutato esattamente anche su Windows 10.
Bourbert,

3

Non hai installato SDK versione 7.0A? Questo è un problema che dovrai risolvere. Cerca nei file di registro dell'installazione di VS2010 per vedere cosa è andato storto. L'SDK deve essere presente in c: \ programmi \ microsoft sdks \ windows \ 7.0a e deve essere presente anche la chiave di registro elencata. L'esecuzione con la versione 6.0a di sgen.exe non va bene, è destinata a utilizzare il compilatore sbagliato.


1
Ricorda, questo è un server di compilazione, quindi l'installazione dell'ambiente VS2010 completo non è stata la mia prima scelta. Non sono riuscito a trovare alcun download disponibile di Windows SDK 7.0a
Scott Mayfield

3
Non vedo il problema. Eseguire una build su una macchina la cui configurazione non corrisponde alle macchine dev, è un problema che ti logorerà rapidamente.
Hans Passant,

3

Impostare Sdk40ToolsPathanziché SdkToolsPathspecificare un percorso diverso dalla directory di installazione.

Ho riscontrato un problema simile con AL.exe perché avevo appena copiato gli strumenti sulla macchina di costruzione anziché installare l'SDK, quindi mancavano le solite chiavi del Registro di sistema. Ho eseguito una build con output diagnostico (/ verbosità: diagnostica) e ho notato che c'erano diversi percorsi degli strumenti SDK definiti: Sdk40ToolsPath, Sdk35ToolsPath e SdkToolsPath. L'impostazione di Sdk40ToolsPath in modo che punti alla cartella bin della versione SDK appropriata ha risolto il problema per me.


Dove hai impostato Sdk40ToolsPath?
Michael Freidgeim,

Suppongo che debba essere aggiunto al percorso dell'ambiente. Tuttavia, non ha funzionato per me.
Timothy Lee Russell,

Mi dispiace che sia stato tanto tempo fa che ho dimenticato i dettagli, ma penso che fosse una variabile di ambiente o impostata nel file di progetto MSBuild. Si noti inoltre che la domanda originale riguarda .NET Framework 4.0 / VS2010 ma potrebbero essere necessarie variabili diverse per le versioni successive del framework.
IanS

2

Sono d'accordo con la risposta di IanS. Non è necessario installare un nuovo SDK. Assicurati solo che i valori della chiave di registro SDK35ToolsPath e SDK40ToolPath per MSBuild puntino a valori di chiave di registro corretti.

Nel mio caso il mio progetto era destinato a .NET 3.5 e ho dovuto impostare SDK35ToolsPath per la chiave HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 su $ (Registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v6.0A \ WinSDKNetFxTools @ InstallationFolder). E tutto ha funzionato.


2

Abbiamo un PC build WinXP e utilizziamo Visual Build Pro 6 per creare il nostro software. poiché alcuni dei nostri sviluppatori usano VS 2010 i file di progetto ora contengono riferimenti a "tool versione 4.0" e da quello che posso dire, questo dice a Visual Build che deve trovare un sdk7.x da qualche parte, anche se costruiamo solo per .NET 3.5 . Ciò ha causato non trovare lc.exe. Ho provato a ingannarlo indicando tutte le macro allo sdk 6.0A fornito con VS2008 che è installato sul PC, ma non ha funzionato.

Alla fine ho funzionato scaricando e installando sdk 7.1. Ho quindi creato una chiave di registro per 7.0A e ho indicato il percorso di installazione sul percorso di installazione di 7.1 SDK. ora trova felicemente un "lc.exe" compatibile e tutto il codice viene compilato correttamente. Ho la sensazione che ora sarò anche in grado di compilare il codice .NET 4.0 anche se VS2010 non è installato, ma non l'ho ancora provato.


2

ToolsVersion = "4.0" lo fa per me nel mio progetto MSBuild:

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

Bene, nel mio caso ho usato ToolsVersion = "14.0" per VS 2015 e questo ha risolto il problema
AndrewSilver,

2

Innanzitutto assicurati di aver già scaricato dotNetFx40_Full_x86_x64.exe e installato (è comunemente associato a Visual Stdio).

Quindi impostare rapidamente una nuova variabile d'ambiente sulle variabili di sistema. come sotto: "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.


Questo sta risolvendo il problema. Solo un suggerimento se qualcuno ha lo stesso problema di I. La variabile Env deve essere chiamata TargetFrameworkSDKToolsDirectory e non SdkToolsPath !!!
Markus,

1

Ho avuto lo stesso problema e avevo installato Windows SDK 7.0 e Windows SDK 7.1 che non hanno risolto il problema. La causa del problema per me è stata che la libreria di classi offensiva è stata creata con Target Framework di .NET Framework 2.0.

L'ho cambiato in .NET Framework 4.0 e ho funzionato localmente e quando ho fatto il check-in nel server Build lo ha creato con successo.


1

Ho avuto un problema simile, in particolare msbuild non riesce: MSB3086, MSB3091: "AL.exe", "resgen.exe" non trovato

Su una macchina Windows 7 a 64 bit, ho installato .Net framework 4.5.1 e Windows SDK per Windows 8.1.

Sebbene le configurazioni per l'SDK dicessero che era aggiornato, probabilmente non lo era. Ho risolto il problema rimuovendo tutte le versioni installate di SDK, quindi installando quanto segue, in questo ordine:

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

Risposta breve: nel file .csproj esiste un modo per specificare il percorso di sgen.exe, usando 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>

Il tuo percorso potrebbe essere diverso, ma SGenToolPath è quello che vuoi.

Per un elenco di altre proprietà comuni del progetto MSBuild, vedere: https://msdn.microsoft.com/en-us/library/bb629394.aspx

Abbiamo finito per usare questa impostazione SGenToolPath nel file .csproj, invece di modificare i valori di registro sul server di compilazione. Anche la modifica dei valori di registro sul mio computer locale aveva funzionato, ma era un po 'più complicata e non volevamo rovinare il registro sul server di compilazione.

Per il registro: in quel caso il problema era che gli SDK40ToolsPath in HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild puntavano a un valore di registro $ (Registry: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86 @ InstallationFolder) che non esisteva. L'ho appena sostituito direttamente con il percorso effettivo.


1

Anch'io ho riscontrato questo problema durante il tentativo di creare un plug-in utilizzando Visual Studio 2017 sul mio computer sul posto di lavoro orribilmente incasinato. Se cerchi su Internet "impossibile trovare resgen.exe", puoi trovare tutti questi consigli come ' basta usare regedit per modificare il registro di Windows e creare una nuova chiave qui e copiare e incollare il contenuto di questa cartella in quest'altra cartella, blah blah blah.'

Ho trascorso settimane a rovinare il mio registro di Windows con regedit, probabilmente ho aggiunto una dozzina di sottochiavi e ResGen.exe incollato in molte directory diverse, a volte mettendolo in una cartella "bin", a volte semplicemente conservandolo nella cartella principale, eccetera.

Alla fine, mi sono reso conto, "Ehi, se Visual Studio avesse fornito un messaggio di errore più dettagliato, nulla di tutto questo sarebbe stato un problema". Quindi, per ottenere maggiori dettagli sull'errore, ho eseguito MSBuild.exe direttamente sul mio file * .csproj dalla riga di 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"

Naturalmente, dovrai modificare i dettagli del percorso per adattarli alla tua situazione, ma assicurati di mettere 1) il percorso completo di MSBuild.exe 2) il percorso completo del tuo file * .csproj 3) il -fl -flp: logfile = parte, che dirà a MSBuild di creare un file di registro di ogni passaggio effettuato nel processo, 4) la posizione in cui si desidera salvare il file * .log e 5); verbosità = diagnostica, che sostanzialmente dice a MSBuild per includere tonnellate di dettagli nel file * .log.

Dopo aver fatto ciò, la compilazione fallirà come sempre, ma ti verrà lasciato un file * .log che mostra esattamente dove MSBuild ha cercato il tuo file ResGen.exe. Nel mio caso, vicino alla fine del file * .log, ho trovato:

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"

Quindi sostanzialmente, MSBuild ha cercato ResGen.exe in cinque directory separate , poi ha rinunciato. Questo è il tipo di dettagli che non è possibile ottenere dal messaggio di errore di Visual Studio e risolve il problema: utilizzare semplicemente regedit per creare una chiave per una di queste cinque posizioni e inserire il valore "InstallationFolder" nella chiave , che dovrebbe puntare alla cartella in cui risiede ResGen.exe (nel mio caso era "C: \ Programmi \ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.7.2 Tools").

Se sei un esperto di discipline umanistiche come me senza precedenti nei computer, potresti essere tentato di modificare il diavolo dal registro di Windows e copiare e incollare ResGen.exe ovunque di fronte a un errore come questo (che è ovviamente, cattiva pratica). È meglio seguire la procedura descritta sopra: 1) Esegui MSBuild.exe direttamente sul tuo file * .csproj per scoprire la posizione esatta in cui MSBuild sta cercando ResGen.exe, quindi 2) modifica il registro di Windows in modo che MSBuild possa trovare ResGen. EXE.


Ho provato questo, ma per qualche motivo non ottengo l'elenco dei percorsi visualizzati. Ho trovato un post simile al tuo su questo sito: community.sdl.com/developers-more/developers/… quindi so che dovrebbe funzionare, ma senza risultati. Quale versione di MSBuild stai usando?
user11809641

Sembra che sto usando MSBuild versione 4.0.30319. Ho anche installato la versione 3.5, 3.0 e 2.0.50727 su questo computer. Ho provato a eseguire quelle versioni di MSBuild sul mio file * .csproj (nello stesso modo descritto sopra), ma non ha funzionato ... non ha nemmeno creato un file * .log. /// Quando esegui MSBuild sul tuo file * .csproj, il computer produce almeno un file * log? La mia comprensione è che esiste un file di registro, ma nessuna informazione specifica relativa ai percorsi che sono stati cercati durante la ricerca di ResGen.exe - è corretto?
todbott

Sembra che io abbia la stessa versione di MSBuild (4.0.30319). E sì, hai ragione. Ricevo un file di registro, ma non fornisce alcuna informazione sui percorsi del registro. Quale dei cinque percorsi che hai postato sopra hai utilizzato?
user11809641

Ho usato il primo percorso dell'elenco - ho appena aggiunto un "InstallationFolder" nella chiave SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86. Inoltre, il file * .log è in realtà estremamente lungo - migliaia di righe, nel mio caso. Non sono riuscito a trovare le informazioni sul percorso a occhio nudo. Ho finito per aprire il file * .log nel Blocco note e cercare "ResGen.exe", che ha portato alla mia attenzione l'area pertinente (informazioni sui percorsi).
todbott

1
Super - congratulazioni! Sei diventato uno di una manciata di persone (poche centinaia, immagino) che hanno combattuto attraverso errori e mistero e in realtà hanno compilato con successo un plugin per Trados. Buona fortuna con la pubblicazione dei tuoi plugin, ci vediamo sull'App Store SDL!
todbott

1

L'ho corretto passando questo come parametro della riga di comando a msbuild.exe:

Il chilometraggio varia in base alla versione dell'SDK disponibile sul sistema

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

0

Oltre alle mod del Registro di sistema, potrebbe essere necessario modificare la versione di .net sdk su cui sono state impostate le impostazioni in Visual Studio.

Stavo avendo questo problema e ho deciso di controllare le impostazioni di debug del progetto.

Progetto => Proprietà barra degli strumenti => Pulsante Opzioni di compilazione anticipo debug

Il Framework di destinazione (tutte le configurazioni) era impostato su 3.0 che non si trova sul mio sistema.

L'ho modificato in 4.0, quindi ho dovuto riavviare il progetto e Visual Studio 2010.

Il progetto è stato quindi creato senza errori ed eseguito.


Ho fatto un errore è individuare quanto segue. Progetto => Proprietà barra degli strumenti => Pulsante di compilazione avanzato Opzioni di compilazione Ho anche creato un nuovo progetto e il nuovo progetto .net è stato impostato su 3.0. Quindi sarà necessario modificare anche l'impostazione predefinita. Scott A. Tovey
Scott Tovey

Ho scoperto che quando si crea un progetto, nella parte superiore della finestra c'è un elenco a discesa di tutti i framework. Tutto è elencato indipendentemente dal fatto che sia installato o meno. Una volta selezionato un framework e creato un progetto da quell'elenco, rimane il valore predefinito fino a quando non lo si cambia in un altro framework per un nuovo progetto. Questo è un po 'sconsiderato, l'elenco dovrebbe contenere solo framework installati sul sistema.
Scott Tovey,

0

Ho avuto un problema simile. Avevo fatto un progetto usando Visual Studio 2010e poi ho ottenuto l'errore sopra quando l'ho compilato usando Visual Studio 2012. Ho semplicemente copiato tutto il contenuto di C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0AinC:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A e che ha risolto il mio problema.


3
Vorrei che ci fosse un voto per la peggiore soluzione del mondo. Questo sarebbe.
jonypony3,

0

Ho appena avuto questo errore con un file .sln creato originariamente in Visual Studio 2010 (e creato da Visual Studio 2010 e TFS 2010). Ho modificato il file della soluzione per NON creare un progetto che non doveva essere creato in una particolare configurazione e Visual Studio ha modificato l'intestazione del file della soluzione da:

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

Per:

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

Il ripristino della versione originale del 2010 ha risolto il mio problema. Suppongo che la compatibilità con le versioni precedenti di Visual Studio non sia stata ancora perfezionata.


0

prova a usare la "riparazione" di Visual Studio. Ha funzionato per me.


0

Wrapper CMD
Ho provato tutte le cose da qui e anche di più. Niente mi ha aiutato.

Ho applicato un wrapper CMD per MSBuild e DevEnv.com.
L'idea principale all'interno di un tale wrapper è quella di creare un ambiente preparato chiamando i prompt dei comandi dalla fornitura di Visual Studio. E quindi passare i parametri di input standard a una chiamata di MSBuild o DevEnv.com.

Ad ogni modo, sul mio build-server ora posso costruire progetti da diverse versioni di Visual Studio.

Come usare
ho dovuto sostituire le chiamate a MSBuild e DevEnv con una chiamata ai miei wrapper di file batch.
E non ho modificato alcun parametro di input. Come esempio per la mia chiamata al wrapper MSBuild:

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

Soluzione pronta
In effetti, ho avuto molti più problemi con una migrazione da VS 2010 a VS 2015. Ma questa è stata la prima e la più dura.
Quindi, la mia modesta ricetta di salvataggio per un Build Server è qui. Forse è difficile capire tutto questo stile CMD fin da subito, ma spero che qualsiasi logica sia ovvia.

Suggerimenti
Ci sono
MSBuild Command Prompt for Visual Studioe Developer Command Prompt for Visual Studio
li uso in modo appropriato per MSBuild e DevEnv.com. Ma probabilmente il prompt dei comandi di MSBuild sarà sufficiente.

Per VS 2015 questi prompt dei comandi sono qui C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ . O guarda attraverso il menu dei programmi di Windows.

Per passare tutti i parametri di input a MSBuild o DevEnv all'interno di un file batch che ho usato CALL MSBuild %*

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.