VS2012 $ (esiste) accetta solo valori scalari

Question

Ok, questo è più un errore di compilazione che un errore di programmazione. Non ho mai avuto molte ragioni per sporcarmi le mani con le build, quindi questo errore mi lascia sconcertato.

Ho provato googling questo errore con scarsi risultati, le risposte sono o inesistenti, incomprensibili o non applicabili.

L'errore è:

The "exists" function only accepts a scalar value, but its argument 
"$(PackageSourceManifest)" evaluates to "[same path];[same path]" which is not a 
scalar value. C:\Program Files(x86)\MSBuild\Microsoft\VisualStudio\ 
            v10.0\Web\Microsoft.Web.Publishing.targets 

In ogni caso, ho scavato nel Microsoft.Web.Publishing.targets e ho trovato la linea dove è erroring fuori. Ho dei verbosi basati su dove stavo tentando di vedere se potevo trovare tutto ciò che mi rimaneva da risolvere.

Niente.

Ho cercato su google come modificare i manifesti di origine dei pacchetti, ho cercato in Proprietà di costruzione, ho cercato un manifest sorgente o anche qualcosa che dice manifest sorgente, niente. Forse sto cercando troppo o forse non so cosa cercare.

Qualche idea su come risolvere questo problema e che cosa ha causato questo?

Answer 1

aprire il file .csproj e cercare i tag di importazione duplicato.

Nel mio caso il .csproj aveva due linee come questa:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio 
\v10.0\WebApplications\Microsoft.WebApplication.targets" /> 

rimuovere uno di loro risolto il problema.

Answer 2

penso che questo è successo a me quando ho provato a un Web pubblica un progetto in VS2012 che era in origine stato un progetto VS2010. Quindi ricreare il progetto in VS2012 è un modo per curarlo. O come @Giacomelli menziona, cancellando il riferimento alle destinazioni v10.0. Si noti che V10.0 = VS2010 e v11.0 = VS2012

Answer 3

Ho appena avuto lo stesso problema e controllando il mio Csproj file che ho trovato niente di sbagliato, nessuna importazione duplicati - niente.

Dopo inciampo 30 minuti ho preso fissato aprendo il mio file Csproj e riorganizzare i tag in esso.

Inizialmente li ho spostati tutti in alto, ma ho ricevuto un messaggio di errore che OutputPath non è stato definito, quindi li ho spostati tutti sotto la posizione in cui erano definiti e tutto ha funzionato. Tutti tranne:

Molto probabilmente lo spostamento di NuGet.targets dal fondo del file era ciò che effettivamente lo ha risolto. Non ne ho idea, né voglio sprecare altro tempo.

Spero che questo aiuti qualcuno.

Answer 4

Ho avuto lo stesso problema, a causa dell'importazione non corretta di $ MSBuildExtensionsPath32 $. È ovvio che v10.0 è per VS2010 mentre sei su VS2012 (v11.0).

Pertanto, cambiare la vostra importazione:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" /> 

Per altro, se avete VS2013 (v12.0), è possibile modificarla in:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" /> 

Nota: se rimuovi questa riga come suggerito da @giacomelli, non sarai in grado di definire il tuo file di destinazione personalizzato.

Da MSDN: MSBuildExtensionsPath32

http://msdn.microsoft.com/en-us/library/ms164309.aspx

introdotto in .NET Framework 4: non c'è differenza tra i valori di default di MSBuildExtensionsPath e MSBuildExtensionsPath32. È possibile impostare l'ambiente MSBUILDLEGACYEXTENSIONSPATH variabile a un valore non nullo per attivare il comportamento del valore predefinito di MSBuildExtensionsPath nelle versioni precedenti. In .NET Framework 3.5 e versioni precedenti, il valore predefinito di MSBuildExtensionsPath punta al percorso della sottocartella MSBuild nella cartella \ Programmi \ o \ Programmi Files (x86), a seconda della versione del processo corrente. Ad esempio, per un processo a 32 bit su un computer a 64 bit, questa proprietà punta alla cartella \ Programmi (x86). Per un processo a 64 bit su un computer a 64 bit , questa proprietà punta alla cartella \ Programmi. Non includere nella barra rovesciata finale su questa proprietà. Questa posizione è un posto utile per inserire i file di destinazione personalizzati . Ad esempio, i file di destinazione potrebbe essere installato in \ Programmi Files \ MSBuild \ MyFiles \ Northwind.targets e poi importata in progetto file utilizzando questo codice XML:

Answer 5

avuto lo stesso problema in VS 2012 -

Error 48 04115: The "exists" function only accepts a scalar value, but its argument "@(_UnmanagedRegistrationCache)" evaluates to "obj\TheQueueData.sqlproj.UnmanagedRegistration.cache;obj\TheQueueData.sqlproj.UnmanagedRegistration.cache" which is not a scalar value. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 1091 7 TheQueueData 

chiusura e riapertura la soluzione ha fatto il trucco per me.

Answer 6

Ho avuto un problema simile in VS2013. Non ho avuto duplicati La soluzione che ha funzionato per me era la pulizia della cache di Visual Studio. http://blogs.msdn.com/b/willy-peter_schaub/archive/2010/09/15/if-you-have-problems-with-tfs-or-visual-studio-flush-the-user-cache-or-not.aspx

Answer 7

ho ottenuto lo stesso errore in VS2013, ma solo quando cerco di ricostruire il progetto. Di seguito, come risolvo il problema nelle mie condizioni, spero che sia utile anche ad altre persone.

Configurazione:

• ho i miei file dattiloscritto in progetti separati nella soluzione.
• Questi progetti sono stati emigrare per VS 2012.

Causa: quando clicco su l'errore nel file Microsoft.Web.Publishing.targets ho scoperto che il progetto stava usando la versione VS2012 di tali file .Questo è il progetto in cui solo parzialmente migrato da VS2012 a VS2013.

Soluzione: Aprire il progetto dattiloscritto (prima scaricare progetto) Cerca:

 <PropertyGroup> 
     <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">12.0</VisualStudioVersion> 
     <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> 
     </PropertyGroup> 

• commento della linea VSToolsPath
• Salvare e chiudere il file

• ricaricare il progetto È possibile visualizzare una schermata di migrazione da Visual Studio che notifica che il progetto è stato aggiornato.

  ricostruire il progetto, ora dovrebbe funzionare