Come utilizzare Travis-CI con C # o F #

Il servizio di integrazione continua di Travis CI supporta ufficialmente molte lingue , ma non C # o F #.

Posso usarlo con i miei progetti .net?

Travis CI ora supporta C # . Citando liberamente da quella pagina:

Panoramica

L’installazione per i progetti C #, F # e Visual Basic si presenta così:

language: csharp solution: solution-name.sln mono: - latest - 3.12.0 - 3.10.0 

copione

Di default Travis eseguirà xbuild solution-name.sln. Xbuild è uno strumento di compilazione progettato per essere un’implementazione per lo strumento MSBuild di Microsoft. Per sovrascriverlo, puoi impostare l’attributo di script in questo modo:

 language: csharp solution: solution-name.sln script: ./build.sh 

NuGet

Per impostazione predefinita, Travis eseguirà il ripristino nuget nome-soluzione.sln, che ripristina tutti i pacchetti NuGet dal file della soluzione. Per sovrascriverlo, puoi impostare l’attributo di installazione in questo modo:

 language: csharp solution: solution-name.sln install: - sudo dosomething - nuget restore solution-name.sln 

Vedi la risposta di danielnixon per il modo ufficiale di farlo ora.

È ansible.

1. Il tuo progetto deve lavorare su Mono

Sulla propria macchina mono, usando il terminale, cd nella directory della soluzione ed eseguendo il comando xbuild . Questo potrebbe funzionare automaticamente, oppure no, dato che ci sono funzioni che hai usato in Visual Studio che necessitano di qualche ritouch in mono.

Cose da cercare:

  • Errori di file mancanti, verificare che il caso dei nomi dei file corrisponda a .csproj linux abbia percorsi sensibili al maiuscolo / minuscolo in cui Windows non lo fa.
  • Nuget richiede l’ export EnableNuGetPackageRestore=true prima di eseguire xbuild se il tuo progetto ripristina automaticamente.
  • La tua istanza mono non può avere certificati SSL root, usa mozroots --import --sync per installarli.
  • Inoltre, se vedi errori di file mancanti, nuget.* Invece di NuGet.* riferimenti nel tuo .csproj sono stati conosciuti per esistere in varie versioni di nuget.
  • C’è un bug nel file di destinazione di 2.5 nuget basato su spazi nel file .target, soluzione qui
  • Per il supporto di FSharp 3.0 è necessario il mono 3.0.X o successivo (e potrebbe essere necessario compilare dal sorgente, ma installato di default su Mac OS X)
  • Per i progetti FSharp di VS2013, potrebbe essere necessario modificare il file .fsproj per triggersre la configurazione di VS2012 su macchine non Windows aggiungendo '$(VisualStudioVersion)' == '11.0' Or $(OS) != 'Windows_NT' vedere l’ esempio .

Mono 3.1.12, 3.2.4 e successive

  • Mono 3.1.2, 3.2.4 e successivi hanno il supporto per pcl, ma possono anche avere gli errori PCL mancanti. Cerca l’errore elencato sotto sotto Mono 3.0.12 in quanto include solo i seguenti riferimenti di framework:
    • v4.0, Profile136 .NET Framework 4, Silverlight 5, Windows Phone 8, App di Windows Store (Windows 8)
    • v4.0, Profile14 .NET Framework 4, Silverlight 5
    • v4.0, Profile147 .NET Framework 4.0.3, Silverlight 5, Windows Phone 8, App di Windows Store (Windows 8)
    • v4.0, Profile158 .NET Framework 4.5, Silverlight 5, Windows Phone 8, App di Windows Store (Windows 8)
    • v4.0, Profile19 .NET Framework 4.0.3, Silverlight 5
    • v4.0, Profile24 .NET Framework 4.5, Silverlight 5
    • v4.0, Profile37 .NET Framework 4, Silverlight 5, App di Windows Store (Windows 8)
    • v4.0, Profile42 .NET Framework 4.0.3, Silverlight 5, App di Windows Store (Windows 8)
    • v4.0, Profile47 .NET Framework 4.5, Silverlight 5, App di Windows Store (Windows 8)
    • v4.0, Profile5 .NET Framework 4, app di Windows Store (Windows 8)
    • v4.0, Profile6 .NET Framework 4.0.3, app di Windows Store (Windows 8)
    • v4.5, Profile49 .NET Framework 4.5, Windows Phone 8
    • v4.5, Profile7 .NET Framework 4.5, app di Windows Store (Windows 8)
    • v4.5, Profile78 .NET Framework 4.5, Windows Phone 8, app di Windows Store (Windows 8)

Mono 3.0.12

  • Mono 3.0.12 ha gli obiettivi per le librerie di classi portatili ma non gli assiemi di riferimento. Cerca Unable to find framework corresponding to the target framework moniker '.NETPortable,Version=v4.0,Profile=ProfileX'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior. Unable to find framework corresponding to the target framework moniker '.NETPortable,Version=v4.0,Profile=ProfileX'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior. Utilizzare le condizioni della piattaforma (menzionate in Mono 3.0.11 o precedenti ) o eseguire l’aggiornamento alla 3.1.2.

Mono 3.0.11 o precedente

  • Errori di Target mancanti, se non è nuget, è probabilmente perché stai usando una destinazione di libreria di classi Portable o altra destinazione che non esiste. Se il tuo progetto può essere compilato per .net 4.0, puoi modificare il tuo .csproj o .fsproj, in modo che su .net si costruisca in modo portatile e su mono per .net 4.0. fondamentalmente da elementi separati in gruppi di proprietà condizionali Profile46 o Condition="$(OS) != 'Windows_NT' per mono. Il tuo chilometraggio può variare. Vedi l’ esempio di lavoro.

Mono 2.10.X

  • Anche in Mono v2.10 mancano alcune delle classi Microsoft.Build di cui Nuget ha bisogno, è ansible copiare la DLL v3.0.X, che è molto piccola, nella directory .nuget. (L’ho usato qui )

2. Essere in grado di eseguire unit test dalla riga di comando.

.ci/nunit.sh è il mio script di shell per il testing di nunit, controllato nella root del repository. Quindi posso installare la versione nunit-console che voglio con nuget e configurare varie inclusioni / esclusioni anche delle categorie. Il tuo chilometraggio può variare, ma questa tecnica dovrebbe funzionare per xunit ecc. O fare le tue cose con xbuild o falso .

.ci / nunit.sh

 #!/bin/sh -x mono --runtime=v4.0 .nuget/NuGet.exe install NUnit.Runners -Version 2.6.1 -o packages runTest(){ mono --runtime=v4.0 packages/NUnit.Runners.2.6.1/tools/nunit-console.exe -noxml -nodots -labels -stoponerror $@ if [ $? -ne 0 ] then exit 1 fi } #This is the call that runs the tests and adds tweakable arguments. #In this case I'm excluding tests I categorized for performance. runTest $1 -exclude=Performance exit $? 

3. Configura Travis per mono

Mono v3.8.0

Per testare l’ultimo mono è più facile usare gli host Mac (target usando la language:objective-c ogg language:objective-c Mono v3.1.2 e successivamente cambiata la distribuzione su un Mac da un DMG a solo un PKG quindi l’installazione è abbastanza semplice. Librerie di classi, .NET 4.5.1 e FSharp 3.1.

 language: objective-c env: global: - EnableNuGetPackageRestore=true matrix: - MONO_VERSION="3.8.0" before_install: - wget "http://download.mono-project.com/archive/${MONO_VERSION}/macos-10-x86/MonoFramework-MDK-${MONO_VERSION}.macos10.xamarin.x86.pkg" - sudo installer -pkg "MonoFramework-MDK-${MONO_VERSION}.macos10.xamarin.x86.pkg" -target / script: - xbuild - .ci/nunit.sh Tests/bin/Debug/Tests.dll 

Per scegliere come target sia Mono v2.10.X che v3.0.X

Sono facile usare gli host Mac per configurare una matrice di build per più versioni di Mono. Vedi lo script qui sotto

 language: objective-c env: global: - EnableNuGetPackageRestore=true matrix: - MONO_VER="2.10.11" - MONO_VER="3.0.12" before_install: - wget "http://download.mono-project.com/archive/${MONO_VER}/macos-10-x86/MonoFramework-MDK-${MONO_VER}.macos10.xamarin.x86.dmg" - hdid "MonoFramework-MDK-${MONO_VER}.macos10.xamarin.x86.dmg" - sudo installer -pkg "/Volumes/Mono Framework MDK ${MONO_VER}/MonoFramework-MDK-${MONO_VER}.macos10.xamarin.x86.pkg" -target / script: - xbuild - .ci/nunit.sh Tests/bin/Debug/Tests.dll 

Per Linux

  • Vedi la risposta sotto per la nuova definizione beta.

E ora dovresti essere bravo ad usare Travis sul tuo progetto c #.

Questo è il punto chiave: il progetto deve lavorare su Mono. Questo funziona principalmente per progetti in stile libreria ( AWS SDK .NET è un buon esempio), ma richiede più sforzi di sviluppo e disciplina. L’ambiente di sviluppo Linux non funzionerà se si sta sviluppando un progetto per la piattaforma Windows come l’applicazione WPF, il servizio cloud Azure, l’app Windows Phone / Store o persino l’API Web ASP.NET.

AppVeyor CI è un servizio di integrazione continua ospitato per la piattaforma Windows ed è gratuito per progetti open source. È come Travis CI per Windows!

È ansible impostare il processo di compilazione per la soluzione VS.NET, il progetto MSBuild personalizzato, PSake o qualsiasi script PowerShell di un file batch. Inoltre, AppVeyor ha una gestione degli artefatti e una struttura di implementazione incorporati.

Come già accennato, Travis CI ha il supporto beta per C # . È semplice da usare. Anche nunit può essere integrata molto facilmente. Ecco un piccolo esempio di file .travis.yml che esegue test di nunit e segna la compilazione come fallita se almeno un test di un’unità fallisce:

 language: csharp solution: ./src/yoursolution.sln install: - sudo apt-get install nunit-console - nuget restore ./src/yoursolution.sln script: - xbuild ./src/yoursolution.sln - nunit-console ./src/SomeLibrary.Tests/bin/Debug/SomeLibrary.Tests.dll 

Se vuoi usare Travis CI con F #, su GitHub, con FAKE e Packet, allora F # ProjectScaffold è raccomandato:

http://fsprojects.github.io/ProjectScaffold