Microsoft.WebApplication.targets non è stato trovato sul server di compilazione. Qual è la tua soluzione?

Cercare di compilare il mio progetto sul server di generazione mi dà il seguente errore:

Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Ho risolto questo problema alcuni mesi fa, con l'installazione di Visual Studio 2010 su Build Server. Ma ora sto installando un nuovo server da zero e voglio sapere se esiste una soluzione migliore per risolvere questo problema.

Per rispondere al titolo della domanda (ma non alla domanda sull'output che stai ricevendo):

La copia della seguente cartella dal tuo computer di sviluppo al tuo server di build risolve questo problema se si tratta solo di applicazioni web

C: \ Programmi (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications

Rimuovi x86 in base a come si interrompe la tua build. Se hai altri tipi di progetto, probabilmente dovrai copiare l'intera cartella msbuild.

La creazione e la pubblicazione di WAP non è supportata se VS non è installato. Detto questo, se davvero non vuoi installare VS, dovrai copiare tutti i file in %ProgramFiles32%\MSBuild\Microsoft\.

Sarà necessario installare anche lo strumento di distribuzione Web . Penso sia così.

UPD: a partire da VS2017, c'è un carico di lavoro in Build Tools che elimina completamente questo problema. Vedi la risposta di @SOReader .

Se preferisci non modificare nulla sul server di compilazione e desideri comunque che il progetto venga compilato direttamente dal controllo del codice sorgente, potrebbe essere una buona idea mettere i file binari richiesti nel controllo del codice sorgente. Dovrai modificare la sezione delle importazioni nel tuo file di progetto in questo modo:

<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

La prima riga è l'importazione effettiva dalla nuova posizione relativa alla directory della soluzione. La seconda è una versione disattivata ( Condition="false") della riga originale che consente a Visual Studio di considerare ancora il progetto come un valido progetto di applicazione Web (questo è il trucco che VS 2010 SP1 fa da solo).

Non dimenticare di copiare la C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplicationsa BuildTargetscartella sotto il vostro controllo del codice sorgente.

In questo momento, nel 2017, è possibile installare i redist di WebApplication con MSBuildTools. Vai a questa pagina che scaricherà MSBuild 2017 Tools e durante l'installazione fare clic Web development build toolsper installare anche questi target:

Ciò comporterà l'installazione di librerie mancanti C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplicationsper impostazione predefinita

È inoltre possibile utilizzare il pacchetto NuGet MSBuild.Microsoft.VisualStudio.Web.targets , facendo riferimento a essi nei progetti di Visual Studio, quindi modificare i riferimenti come suggerisce Andriy K.

Sulla base di questo post qui puoi semplicemente scaricare il pacchetto ridistribuibile (integrato) di Microsoft Visual Studio 2010 Shell e le destinazioni sono installate.

Ciò evita la necessità di installare Visual Studio sul server di compilazione.

Ho appena provato questo ora e posso verificare che funzioni:

Prima:

errore MSB4019: il progetto importato "C: \ Programmi (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications \ Microsoft.WebApplication.targets" non è stato trovato. Confermare che il percorso nella dichiarazione sia corretto e che il file esista sul disco.

Dopo l'installazione:

[Costruisce correttamente]

Questa è una soluzione di gran lunga migliore rispetto all'installazione di Visual Studio su un server di compilazione, ovviamente.

L'ultimo Windows SDK, come menzionato sopra, oltre al "pacchetto ridistribuibile (integrato) della shell di Microsoft Visual Studio 2010" per Microsoft.WebApplication.targets e "GDR R2 di Database Edition 2008 di Microsoft Visual Studio Team System" per Microsoft.Data.Schema .SqlTasks.targets dovrebbe alleviare la necessità di installare Visual Studio 2010. Tuttavia, l'installazione di VS 2010 potrebbe effettivamente essere meno globale da scaricare e meno lavoro alla fine.

Aggiungi dipendenza tramite NuGet e imposta un parametro di costruzione

Obiettivo: nessuna modifica / installazione necessaria per gli agenti di compilazione

Ho adottato qui un approccio ibrido all'approccio NuGet di Lloyd , basato sull'impegnativa soluzione di dipendenze binarie di Andrik.

Il motivo è che voglio poter aggiungere nuovi agenti di build senza doverli preconfigurare con elementi come questo.

1. Su un computer con Visual Studio, apri la soluzione; ignorare che il progetto Web non riesce.
2. Nel gestore pacchetti NuGet, aggiungi MSBuild.Microsoft.VisualStudio.Web.targets , come menzionato da Lloyd.
3. Questo risolverà i file binari [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
   1. Puoi copiarli in una cartella di riferimenti e confermare,
   2. O semplicemente usali dove sono. Ho scelto questo, ma avrò a che fare con il numero di versione nel percorso più avanti.

Nella versione 7, ho fatto quanto segue. Questo potrebbe non essere stato necessario e sulla base dei commenti non è assolutamente necessario ora. Si prega di vedere i commenti qui sotto.

1. Successivamente, nella configurazione build di TeamCity, aggiungi un build Paramenter per env.VSToolsPathe impostalo nella cartella VSToolsPath; ero solito..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath

Quando si crea sul server build / CI, disattivare l'importazione del Microsoft.WebApplication.targetstutto specificando /p:VSToolsPath=''. Ciò, in sostanza, renderà falsa la condizione della seguente riga:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Ecco come si fa in TeamCity:

Se si esegue la migrazione di Visual Studio 2012 al 2013, aprire il file di progetto * .csproj con edior.
e controlla l'elemento ToolsVersion del tag 'Project'.

Cambia il suo valore da 4.0 a 12.0

• A partire dal

  <?xml version="1.0" encoding="utf-8"?>
  <Project ToolsVersion="4.0" ...

• Per

  <?xml version="1.0" encoding="utf-8"?>
  <Project ToolsVersion="12.0" ...

Oppure se compilate con msbuild, specificate semplicemente la proprietà VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0

Fonte della soluzione

Sembra che la nuova versione di msbuild non sia fornita con Microsoft.WebApplication.targets. Per risolvere il problema, devi aggiornare il tuo file csproj in questo modo:

1) Modifica l'app web csproj (tasto destro). Trova la sezione in csproj verso il basso relativa agli strumenti di costruzione. Dovrebbe apparire così.

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />  

2) Devi aggiungere una riga VSToolsPath sotto il tag VisualStudioVersion in modo che appaia così

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <!--Add the below line to fix the project loading in VS 2017 -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  <!--End -->
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />  

Link di riferimento: https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/

Questo è tutto ciò di cui hai bisogno. Solo 103 MB. Non installare tutto

Ho trovato questo su MS Connect :

Sì, è necessario installare Visual Studio 2010 sul computer di compilazione per creare progetti di database. Ciò non richiede una licenza aggiuntiva di Visual Studio.

Quindi, questa è l'unica opzione che ho per ora.

La mia soluzione è un mix di diverse risposte qui.

Ho controllato il server di compilazione e l'SDK di Windows 7 / NET4.0 era già installato, quindi ho trovato il percorso:

C: \ Programmi (x86) \ MSBuild \ Microsoft \ VisualStudio \ v9.0 \ WebApplications \ Microsoft.WebApplication.targets`

Tuttavia, su questa linea:

<Importa progetto = "$ (MSBuildExtensionsPath) \ Microsoft \ VisualStudio \ v9.0 \ WebApplications \ Microsoft.WebApplication.targets" />

$ (MSBuildExtensionsPath) si espande in C: \ Programmi \ MSBuild che non ha il percorso.

Quindi quello che ho fatto è stato creare un link simbolico, usando questo comando:

mklink / J "C: \ Programmi \ MSBuild \ Microsoft \ VisualStudio" "C: \ Programmi (x86) \ MSBuild \ Microsoft \ VisualStudio"

In questo modo $ (MSBuildExtensionsPath) si espande in un percorso valido e non sono necessarie modifiche nell'app stessa, solo nel server di build (forse si potrebbe creare il link simbolico ogni build, per assicurarsi che questo passaggio non venga perso e sia "documentato" ").

Ho risolto questo aggiungendo
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"

in
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments

Ho provato un sacco di soluzioni, ma alla fine questa risposta ha funzionato per me: https://stackoverflow.com/a/19826448/431522

Fondamentalmente implica la chiamata a MSBuild dalla directory MSBuild, anziché dalla directory di Visual Studio.

Ho anche aggiunto la directory MSBuild al mio percorso, per semplificare la codifica degli script.

Chiunque venga qui per Visual Studio 2017. Ho avuto il problema simile e non sono riuscito a compilare il progetto dopo l'aggiornamento a 15.6.1. Ho dovuto installare gli strumenti di MSBulild ma l'errore era ancora lì.

Sono stato in grado di risolvere il problema copiando la v14.0cartella C:\Program Files (x86)\MSBuild\Microsoft\VisualStudionella stessa cartella di v15.0e che ha risolto tutti gli errori. Quindi ora la mia struttura di cartelle appare come di seguito, dove entrambe le cartelle contengono lo stesso contenuto.

Se stai usando MSBuild, come nel caso di un server di build, ciò che ha funzionato per me è:

Modifica quanto segue:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

per:

<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Il mio comando Msbuild è: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*

Spero che questo aiuti qualcuno.

Nel caso in cui si stia tentando di distribuire un progetto utilizzando VSTS, il problema potrebbe essere collegato al controllo dell'opzione "Contenitore di Windows ospitato" anziché "Hosted VS2017" (o 18, ecc.):

• Dopo l'installazione degli strumenti MSBuild da parte di Microsoft, definire il percorso MSBuild nella variabile d'ambiente, in modo che possa essere eseguito da qualsiasi percorso.
• Modifica il file .csproj in qualsiasi editor di blocco note come notepad ++ e commenta il file
• Verificare i seguenti elementi, ->
  • Assicurati di utilizzare l'importazione una sola volta, scegli quale funziona.
  • Assicurarsi che sull'unità sia presente la seguente cartella, "C: \ Programmi (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0" o la versione a cui fa riferimento la destinazione MSBuild in "C: \ Programmi (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ applicazioni web \ Microsoft.WebApplication.targets"
  • Dal prompt dei comandi, eseguire il comando seguente, per verificare

C:> msbuild "C: \\ DotnetCi.sln" / p: Configuration = Release / p: UseWPP_CopyWebApplication = true / p: PipelineDependsOnBuild = false

• scegliere l'opzione / p come appropriato, fare riferimento per inserire la descrizione del collegamento qui inserire la descrizione dell'immagine qui

Stavo riscontrando questo problema durante la creazione di un progetto SQL Server su una pipeline CI / CD. In effetti, lo avevo anche localmente e non sono riuscito a risolverlo.

Ciò che ha funzionato per me è stato l'utilizzo di un SDK di MSBuild , in grado di produrre un pacchetto di applicazioni di livello dati SQL Server ( .dacpac) da un set di script SQL, il che implica la creazione di un nuovo progetto. Ma volevo mantenere il progetto SQL Server, in modo da poterlo collegare al database live tramite SQL Server Object Explorer su Visual Studio. Ho preso i seguenti passaggi per farlo funzionare:

1. Ho mantenuto il mio progetto SQL Server con .sql script database.
2. Creato un progetto di libreria di classi .NET Standard 2.0, assicurandosi che il framework di destinazione fosse .NET Standard 2.0, secondo le linee guida nel link sopra.

3. Impostare i contenuti di .csprojcome segue:

   <?xml version="1.0" encoding="utf-8"?>
   <Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
     <PropertyGroup>
       <SqlServerVersion>Sql140</SqlServerVersion>
       <TargetFramework>netstandard2.0</TargetFramework>
     </PropertyGroup>
   </Project>

4. Ho scelto Sql140 come versione di SQL Server perché sto usando SQL Server 2019. Controlla questa risposta per scoprire il mapping alla versione che stai utilizzando.

5. Ignora il progetto SQL Server durante la compilazione, in modo che smetta di interrompersi localmente (si basa su Visual Studio, ma non riesce su VS Code).

6. Ora dobbiamo solo assicurarci che i .sqlfile si trovino all'interno del progetto SDK quando viene creato. L'ho raggiunto con una semplice routine PowerShell sulla pipeline CI / CD che avrebbe copiato i file dal progetto SQL Server al progetto SDK:

Copia-Item -Path "Path.To.The.Database.Project \ dbo \ Tables \ *" -Destinazione (New-item -Name "dbo \ Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project \ ")

PS: i file devono trovarsi fisicamente nel progetto SDK, nella cartella principale o in alcune cartelle, quindi i collegamenti ai .sdkfile nel progetto SQL Server non funzioneranno. In teoria, dovrebbe essere possibile copiare questi file con una condizione pre-build, ma per qualche oscura ragione, questo non funzionava per me. Ho anche cercato di avere i .sqlfile sul progetto SDK e di collegarli al progetto SQL Server, ma ciò avrebbe facilmente interrotto il collegamento con Esplora oggetti di SQL Server, quindi ho deciso di abbandonare anche questo.