2010-06-15 5 views
7

Ho una soluzione .NET con un C++ gestito assemlby Targeting .NET 3.5 creato con VS2010. Il comando:Come creare un progetto C++ VS2010 su un BuildServer

%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MyProject.sln 

compila la soluzione sulla mia macchina di sviluppo.

Sul mio buildserver ottengo questo errore:

Build FAILED.

"F:\CruiseControl.NET\Projects\MyProject\MyProject.sln" (default target) (1) -> "F:\CruiseControl.NET\Projects\MyProject\MyProject\MyProject.csproj" (default target) (2) -> "F:\CruiseControl.NET\Projects\MyProject\MyProjectMAPIHelper\MyProjectMAPIHelper.vcxproj" (default target) (3) ->
F:\CruiseControl.NET\Projects\MyProject\MyProjectMAPIHelper\MyProjectMAPIHelper.vcxproj(23,3): error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

0 Warning(s) 
1 Error(s) 

Sulla mia macchina dev file rivendicato

"C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.Default.props"

esiste. Sul mio server di build no.

Quando provo a copiare questi file (e tutti gli altri nella stessa directory) si sono verificati altri errori. Quindi questo è il modo sbagliato.

EDIT: altri errori significa: Quando ho Copiare il file "Microsoft.Cpp.Default.props" sul server di build, MSBuild sta sostenendo altri file. Ciò dimostra che fare una copia dei file mancanti non è ciò che l'ambiente di costruzione si aspetta. Sto cercando un pacchetto MSI/qualunque che potrei installare sul mio server di compilazione e qualsiasi progetto C++ creerà. L'installazione dell'SDK non ha funzionato. O ho fatto qualcosa di sbagliato durante l'installazione dell'SDK. Oppure non è possibile compilare Managed C++ VS2010 Solutions solo con l'SDK.

Credo che "altri errori" non abbia nulla a che fare con il mio problema. Il mio problema è: "Come faccio a configurare correttamente il mio ambiente di costruzione". /EDIT

Quello che ho fatto fino ad ora:

  • Ho installato l'ultima Win7 SDK (http://blogs.msdn.com/b/windowssdk/archive/2010/05/25/released-windows-sdk-for-windows-7-and-net-framework-4.aspx)
  • sto il targeting NET 3.5
  • ho provato a giocare con la proprietà Platform Toolset - ma era solo in riproduzione
  • Nella mia soluzione c'è un assembly C++ gestito (il mio problema)
  • Sto usando MSBuild 4.0 perché i nuovi file di progetto VS2010 non possono essere compilati con MSBuild 3.5
  • Sto utilizzando CC.NET. la compilazione non riesce in CC.NET e sulla riga di comando. Quindi non dovrebbe essere un problema CC.NET.

Esistono trucchi e consigli su come configurare il mio progetto per compilare correttamente sulla mia macchina dev con VS2010 e sul mio server di build? C'è altro da installare (eccetto VS2010)?

Grazie, Arthur

+0

Domanda: Sei collegato a CC.Net o hai la possibilità di passare a qualcos'altro? – Caladain

+2

Non credo che il passaggio a un'altra tecnologia di integrazione continua cambierà nulla. Come dice Arthur, la compilazione fallisce con l'uso di MSBuild. Questo sembra essere un problema con .Net 4.0 più fortemente legato a SDK 7.0A di quanto dovrebbe essere. –

+0

Sì, è vero. la compilazione fallisce sulla riga di comando con MSBuild. CC.NET non è ancora coinvolto. – Arthur

risposta

4

Per ora, l'installazione di VS 2010 è l'unica opzione sicura. Windows SDK verrà aggiornato per abilitare lo scenario, ma non ho una data di rilascio specifica. Fino ad allora, dovrai installare VS 2010 con gli strumenti C++ per creare la tua soluzione 2010 con progetti C++. Assicurati di far sapere al team di C++ di quanto insoddisfazione per questa situazione tramite il loro team blog e/o MSDN Forum.

Anche dopo l'installazione di VS 2010, potrebbe essere necessario richiamare il file vcvars * .bat appropriato per configurare correttamente le variabili di ambiente.

+0

Triste notizia. Se l'installazione dell'SDK non risolve il problema, dovrò installare VS 2010 sul mio computer di compilazione. Triste, ma ovviamente vero. – Arthur

+1

Dopo tanto dolore, ho scoperto che l'SDK 7.1 installa la configurazione necessaria * se * si selezionano le opzioni corrette durante l'installazione e non si tenta di superare in astuzia :). Vedere la risposta breve a http://stackoverflow.com/questions/4742325/how-to-build-a-vs2010-makefile-project-vcxproj-with-tfs-build-no-vs-2010/4768328#4768328 – BlueMonkMN

+0

Come questa risposta è accettabile? Lo scopo di un build server NON è quello di installare Visual Studio ... @BlueMonkMN: Sei/stavi facendo girare una macchina con Windows 7 o una versione server? – Brandon

1

Perché non si desidera installare VS2010 sul server di build? Se si tratta di licenze, è concesso in licenza per capo sviluppatore e non per installazione, quindi sono ragionevolmente sicuro che ti sia permesso senza acquistare un'altra copia o, nel peggiore dei casi, puoi installare la versione rapida che dovrebbe almeno installare i bit di configurazione che sei mancante in modo da poter utilizzare il compilatore di piattaforma SDK.

Se si riscontrano ancora problemi con msbuild, è possibile utilizzare devenv.com /build che replica esattamente VS env di VS.

+2

L'installazione di VS2010 sarà la mia ultima opzione. – Arthur

+0

@Rup L'installazione di VS su un server di build è una pessima idea. È esattamente l'opposto di ciò che un server di sviluppo è per: fornire un ambiente pulito, simile al cliente (DLL esistenti ecc.). Se pensi che l'installazione di VS sul server di generazione non sia un problema, allora devi anche suggerire di installare VS su ogni box del cliente. – mafu

+0

@mafutrct Vedo da dove vieni ma non c'è motivo per cui tu debba ospitare e testare l'applicazione sul tuo server di build! Quando ho scritto che il nostro ambiente era un server di build per i test unitari e alcuni test di integrazione ma una distribuzione automatica su un altro server (che non aveva VS) per veri test. – Rup