2012-07-06 14 views
8

Ho un progetto che utilizza SpecFlow, NUnit e Coypu per eseguire test di accettazione su un'applicazione web. Ho il progetto di costruire OK tramite Jenkins su un server di build. Jenkins chiama uno script psake che esegue msbuild sul progetto specs, quindi lo script chiama nunit-console per eseguire le specifiche/test, e poi voglio generare un report da SpecFlow.specflow non riesce quando si tenta di generare report di esecuzione del test

Framework "4.0" 

task Default -depends RunSpecs 

task BuildSpecs { 
    $env:EnableNuGetPackageRestore = "true" 
    msbuild /t:Rebuild ReturnsPortal.Specs.csproj 
} 

task RunSpecs -depends BuildSpecs { 
    exec { & "C:\path\to\NUnit 2.5.9\bin\net-2.0\nunit-console-x86.exe" /labels /out=TestResult.txt /xml=TestResult.xml .\bin\Debug\TheWebApp.Specs.dll } 
    exec { & "C:\path\to\SpecFlow\1.8.1\specflow.exe" nunitexecutionreport TheWebApp.Specs.csproj /out:SpecResult.html } 
} 

L'ultima chiamata exec di specflow.exe non riesce, però, con:

L'elemento < ParameterGroup> sotto elemento < UsingTask> è riconosciuto. C: \ Program Files (x86) \ Jenkins \ lavori \ TheWebApp \ workspace \ Web \ Siti \ TheWebApp.nuget \ nuget.targets

Un po 'di googling suggerimenti che forse è un problema con la versione in uso msbuild (ad es. here, here). Ma ho lo Framework "4.0" nel mio script psake e il progetto Specs ha come obiettivo .NET Framework 4.0 e si integra perfettamente nel passaggio di generazione, quindi non sono sicuro del motivo per cui specflow sembra utilizzare una versione precedente di msbuild. O forse è il problema da qualche altra parte?

+0

hai provato a passare il percorso completo a msbuild? ('C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ MSBuild.exe') – KMoraz

+0

Grazie, sarebbe il problema, tuttavia non so come forzare SpecFlow ad utilizzare una determinata versione di msbuild. – ngm

risposta

29

Questa è stata la risposta per me, dal SpecFlow Wiki:

importante per NET 4.0 progetti: Perché specflow.exe è compilato per .NET 3.5, esso non può caricare NET 4.0 assembly per impostazione predefinita. Per generare questo report per i progetti .NET 4.0, è necessario forzare specflow.exe per utilizzare il runtime .NET 4.0 utilizzando il file di configurazione. Basta copiare la configurazione di seguito e creare un file specflow.exe.config e metterlo accanto al tuo specflow.exe e sarai in grado di creare il rapporto di definizione del passo.

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <startup> 
     <supportedRuntime version="v4.0.30319" /> 
    </startup> 
</configuration> 
+0

SpecFlow 2.0 è stato rilasciato il 27 gennaio 2016, compilato su .NET 4.5. Questo problema non dovrebbe verificarsi nella nuova versione. – ngm

2

ho cercato di usare il file di configurazione soluzione suggerita sopra. Ha funzionato per testare localmente, ma non appena ho spinto il mio codice nel nostro ambiente CI è stato soffocato perché l'ambiente CI non ha quel file di configurazione. Limitiamo l'ambiente CI a utilizzare solo versioni pulite dei vari pacchetti, quindi non volevamo provare a inserire la configurazione speciale nel server CI.

Abbiamo notato che SpecFlow funziona perfettamente con molti dei nostri progetti .NET 4.0 senza il file di configurazione speciale. Dopo una piccola ricerca, il vero "problema" sembra essere NuGet 2.1. Tutto funziona correttamente per i progetti .NET 4.0 con NuGet 1.7.

Da qualche parte tra 1.7 e 2.1 NuGet ha introdotto nuove funzionalità nel file NuGet.targets che non sono supportate dalle versioni precedenti di MSBuild. In particolare il problema sembra essere il <ParameterGroup> sotto l'elemento <UsingTask>, come spiegato dal messaggio di errore.

Un'occhiata superficiale al file dei target indica che la sezione è responsabile della conservazione di NuGet. La rimozione di questa sezione risolve completamente il problema nello stesso modo in cui aggiunge il file di configurazione sopra riportato, anche se rimuove anche la funzionalità di auto aggiornamento che sembra fornire. Dato che il file .targets è impegnato nel repository, questa soluzione funziona anche sul nostro ambiente CI senza modifiche sul lato CI.

Non è necessariamente una soluzione migliore di quella di ngm, è solo un'altra. A seconda del tuo ambiente, questo potrebbe essere un modo preferibile per andare, o forse no.

+2

Idealmente, SpecFlow offrirebbe un pacchetto compilato per .NET 4.0, che dovrebbe risolvere tutti questi problemi, ma sembra che non siano interessati a farlo in questo momento. – Mir

Problemi correlati