92

Travis CI continuous integration service officially supports many languages, but not C# or F#.

Can I use it with my .net projects?

jbtule
  • 31,383
  • 12
  • 95
  • 128

5 Answers5

151

See danielnixon's answer for the official way to do this now.

It is possible.

1. Your project needs to work on Mono

On your own mono machine, using the terminal, cd into your solution directory and running the command xbuild. This may automatically work, or it may not, as there are features you used in visual studio that need some tweaking in mono.

Things to look out for:

  • Missing files errors, check to make sure the case of file names matches your .csproj linux has case sensitive paths where windows doesn't.
  • Nuget requires you to export EnableNuGetPackageRestore=true before running xbuild if your project auto restores.
  • Your mono instance may not have root SSL certificates, use mozroots --import --sync to install them.
  • Also if you see missing file errors, nuget.* instead of NuGet.* references in your .csproj have been know to exist in various versions of nuget.
  • There is a bug in 2.5 nuget's target file based on whitespace in the .target file, workaround here
  • For FSharp 3.0 support you need mono 3.0.X or later (and may need to build from source, but installed by default on Mac OS X)
  • For FSharp projects from VS2013, you might need to edit your .fsproj to trigger the VS2012 configuration on non windows machines by adding '$(VisualStudioVersion)' == '11.0' Or $(OS) != 'Windows_NT' see example.

Mono 3.1.12, 3.2.4 and later

  • Mono 3.1.2, 3.2.4 and later have pcl support, but can also have the missing PCL errors. Look out for the error listed below under Mono 3.0.12 as it only includes the following framework references:
    • v4.0, Profile136 .NET Framework 4, Silverlight 5, Windows Phone 8, Windows Store apps (Windows 8)
    • v4.0, Profile14 .NET Framework 4, Silverlight 5
    • v4.0, Profile147 .NET Framework 4.0.3, Silverlight 5, Windows Phone 8, Windows Store apps (Windows 8)
    • v4.0, Profile158 .NET Framework 4.5, Silverlight 5, Windows Phone 8, Windows Store apps (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, Windows Store apps (Windows 8)
    • v4.0, Profile42 .NET Framework 4.0.3, Silverlight 5, Windows Store apps (Windows 8)
    • v4.0, Profile47 .NET Framework 4.5, Silverlight 5, Windows Store apps (Windows 8)
    • v4.0, Profile5 .NET Framework 4, Windows Store apps (Windows 8)
    • v4.0, Profile6 .NET Framework 4.0.3, Windows Store apps (Windows 8)
    • v4.5, Profile49 .NET Framework 4.5, Windows Phone 8
    • v4.5, Profile7 .NET Framework 4.5, Windows Store apps (Windows 8)
    • v4.5, Profile78 .NET Framework 4.5, Windows Phone 8, Windows Store apps (Windows 8)

Mono 3.0.12

  • Mono 3.0.12 has the targets for Portable Class Libraries but not the reference assemblies. Look for 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. Use Platform Conditions (mentioned under Mono 3.0.11 or earlier) or upgrade to 3.1.2.

Mono 3.0.11 or earlier

  • Missing Target errors, if it's not nuget, it's probably because you are using a Portable class library target or other target that doesn't exist. If your project can compile for .net 4.0, you can modify your .csproj or .fsproj, so that on .net it builds portable and on mono it builds for .net 4.0. basically by separate things into conditional property groups <PropertyGroup Condition="$(OS) == 'Windows_NT'"> <TargetFrameworkProfile>Profile46</TargetFrameworkProfile> </PropertyGroup> or Condition="$(OS) != 'Windows_NT' for mono. Your mileage may vary. See working example.

Mono 2.10.X

  • Also Mono v2.10 is missing some of it's Microsoft.Build classes which Nuget needs, you can copy the v3.0.X dll, which is very small, to the .nuget directory. (I used it here)

2. Be able to run unit tests from command line.

.ci/nunit.sh is my own shell script for nunit testing, checked into the root of the repo. So I can install the nunit-console version I want with nuget, and configure various include/excludes of categories too. Your mileage may vary, but this technique should work for xunit etc. Or do your own thing with xbuild or fake.

.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. Configure Travis for mono

Mono v3.8.0

For testing the latest mono it's easiest to use Mac hosts (target by using language:objective-c Mono v3.1.2 and later changed distribution on a Mac from a DMG to just a PKG so the install is quite simple. This template should support Portable Class Libraries, .NET 4.5.1, and 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

To Target both Mono v2.10.X and v3.0.X

I's easy to use Mac hosts to setup up for a build matrix for multiple versions of Mono. See script below

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

For linux

And now you should be good to go to use travis on your c# project.

Community
  • 1
  • 1
jbtule
  • 31,383
  • 12
  • 95
  • 128
  • 22
    That's probably one of the best answers I have ever seen on this site. – Michael Grassman Jun 27 '13 at 02:38
  • Hi, I am try to build a fx4.5 project by Travis CI, but not `sudo installer -pkg`. Could please help me to fix it? Thank you! see, https://travis-ci.org/Aimeast/TestForFirst/builds/13814315 – Aimeast Nov 11 '13 at 17:12
  • `language: objective-c` is necessary for that template, so that it uses the OS X host. – jbtule Nov 11 '13 at 18:23
  • I'm getting CS0246 errors ("type or namespace name could not be found") for ServiceBus, Queue and BrokeredMessage. Any ideas? – saiyancoder Mar 08 '14 at 05:03
  • @Mati is that Windows Azure? I don't think that's mono compatible, but I bet it will work easily on AppVeyor http://stackoverflow.com/a/19164665/637783 – jbtule Mar 08 '14 at 15:44
  • Yes. Windows Azure. I hate it so much. – saiyancoder Mar 08 '14 at 20:47
  • totally awesome answer. Question - why do you use before_install instead of install? – Adam Ralph May 30 '14 at 19:48
  • From practical point of view, it doesn't matter, from a technical point of view, before_install is for global dependencies (like mono), install is for project dependencies (like nuget), however using before_install, install, after_install is only matter of preference as long as the order is right, no worries. – jbtule Jun 02 '14 at 14:32
  • It's worth noting that there is now a community-supported default config (`language: csharp` et al), as described in [this answer](http://stackoverflow.com/a/27413136/2029668). That's probably the way to go now. – couchand Jul 20 '15 at 19:56
  • Maybe, the community support default config is based on linux, which still is less likely to be updateable to the latest unlike Mac OS X (especially with F#). I think once .NET core is released the community definition based on linux will be the way to go. – jbtule Jul 20 '15 at 21:11
  • I want to build WPF. – lindexi Dec 01 '16 at 12:56
  • Ths,now we use the Webhooks to run the center machine to auto build when we push the code. – lindexi Dec 02 '16 at 03:10
25

That's the key point - the project must work on Mono. This mostly works for library-style projects (AWS SDK .NET is a good example) though requires more development efforts and discipline. Linux building environment won't work if you are developing a project for Windows platform such as WPF application, Azure cloud service, Windows Phone/Store app or even ASP.NET Web API.

AppVeyor CI is a hosted continuous integration service for Windows platform and it's free for open source projects. It's like Travis CI for Windows!

You can setup build process for VS.NET solution, custom MSBuild project, PSake or any PowerShell script of batch file. Besides, AppVeyor has built-in artifacts management and deployment framework.

Feodor Fitsner
  • 2,354
  • 16
  • 13
  • 2
    @jbtule Although it is not direct answer to the question it does provide value, since some visitors to this question (me for instance) may be interested in both build server for .net both on mono and MS .net platforms. – steenhulthin Nov 03 '13 at 10:55
  • 1
    Ib addition to this post, wercker recently launched native .NET support as well: http://blog.wercker.com/2013/10/25/introducing_wercker-labs_windows.html – pjvds Nov 08 '13 at 16:50
  • AppVeyor CI is giving me a 503 error when I press the 'sign up' link. Not a great first impression ... – Dan Esparza Mar 11 '14 at 19:39
  • 4
    +1 for AppVeyor, I recently setup two build definitions for a .NET 4.5 application and it is very straight-forward to setup and has a lot of flexibility. The support is very responsive as well, I reported a bug and it was fixed and pushed to production in less than 24 hours. – J c Mar 19 '14 at 17:15
17

Travis CI now supports C#. Quoting liberally from that page:

Overview

The setup for C#, F#, and Visual Basic projects looks like this:

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

Script

By default Travis will run xbuild solution-name.sln. Xbuild is a build tool designed to be an implementation for Microsoft's MSBuild tool. To override this, you can set the script attribute like this:

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

NuGet

By default, Travis will run nuget restore solution-name.sln, which restores all NuGet packages from your solution file. To override this, you can set the install attribute like this:

language: csharp
solution: solution-name.sln
install:
  - sudo dosomething
  - nuget restore solution-name.sln
jbtule
  • 31,383
  • 12
  • 95
  • 128
danielnixon
  • 4,178
  • 1
  • 27
  • 39
8

As already mentioned, Travis CI has beta support for C#. I'ts straight forward to use. Also nunit can be integrated very easily. Here's a small example of a .travis.yml file which runs nunit tests and marks the build as failed if at least one unit test fails:

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
Roemer
  • 2,012
  • 1
  • 24
  • 26
  • Thanks, using this config I was able to run it on travis first time (GH issue with more details https://github.com/o2platform/FluentSharp/issues/47#issuecomment-68171766 ) – Dinis Cruz Dec 27 '14 at 08:00
  • This helped me so much thanks! The only thing I've added was `sudo: required` at the end. Works like a charm. – w0ns88 Mar 02 '17 at 12:45
1

If you want to use Travis CI with F#, on GitHub, with FAKE and Packet, then the F# ProjectScaffold is recommended:

http://fsprojects.github.io/ProjectScaffold

Andrew Olney
  • 691
  • 4
  • 12