Building VS 2017 MSBuild csproj Projects with Mono on Linux

9
votes

I have .NET Core projects I am trying to build using Travis CI on Mac and Linux using the latest Mono and .NET Core 1.0.1 tooling (MSBuild based csproj tooling). They target netstandard1.6.1, net45 and net461. The error I get from Travis CI is:

/usr/share/dotnet/sdk/1.0.1/Microsoft.Common.CurrentVersion.targets(1111,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Does Mono not support VS 2017 MSBuild based csproj projects? How can I get my projects to build?

4
msbuildasp.net-coremono.net-coretravis-ci
If you target .NET Framework profiles, you should use Windows (AppVeyor). .NET Core tooling on Linux should be able to compile against .NET Core profiles. Mono is not needed and it is not .NET Framework (remind). – Lex Li
@LexLi: That's a really bad solution when you want to test that a project's .NET Core builds (at least) work on Linux. I'm facing exactly this problem now... I'm hoping I'll be able to add an answer. – Jon Skeet
@JonSkeet definitely, a bad solution to limit the test cases to run only on Windows and .NET Framework. But Mono is not qualified to replace .NET Framework in this case (as it can add extra weirdness to your test cases, and I face that quite often with my open source projects). – Lex Li
@LexLi: I wasn't suggesting using Mono. I was suggesting working out a way to build/test just the .NET Core parts on Linux. – Jon Skeet
@JonSkeet It's fair. But I wonder how Microsoft could ship necessary bits for Linux (referenced assemblies for .NET Framework on Linux?), as that would not be a small burden. – Lex Li

4 Answers

6
votes

There are two options here, as far as I'm aware:

  • Use the FrameworkPathOverride environment variable as described in this issue to point to them.

  • Restrict your Travis build to only build against .NET Core. This is significantly simpler in my experience.

Here's the Noda Time .travis.yml file I'll be using for Noda Time when I can migrate - it's preliminary to say the least, but it does build...

language: csharp
mono: none
dotnet: 1.0.1
dist: trusty

script:
  - dotnet restore src/NodaTime
  - dotnet restore src/NodaTime.Test
  - dotnet restore src/NodaTime.Serialization.Test
  - dotnet build src/NodaTime -f netstandard1.3
  - dotnet build src/NodaTime.Test -f netcoreapp1.0
  - dotnet build src/NodaTime.Serialization.Test -f netcoreapp1.0
  - dotnet run -p src/NodaTime.Test/*.csproj -f netcoreapp1.0 -- --where=cat!=Slow
  - dotnet run -p src/NodaTime.Serialization.Test/*.csproj -f netcoreapp1.0

A few notes on this:

  • Unlike earlier SDKs, we now need to restore each project separately - no big "dotnet restore at the top level" :(
  • I was surprised when this didn't run on dist: xenial, but it didn't. (It claims the environment doesn't support .NET Core.) My guess is this will change.
  • We're using NUnit, and at the moment the only way of testing in the new SDK is to use NUnitLite, hence dotnet run to run tests
  • I'm slightly surprised I can't just specify the directory name for dotnet run (as per dotnet restore and dotnet build) but that seems to be the way of things. I'll hunt down a bug report...

In either case, I'd recommend also having a Windows-based CI build to check that everything builds and works on Windows (ideally testing each framework you support).

1
votes

As of yesterday (May 5th), @dasMulli pointed out that Mono released Mono 5.0 Beta 2 (5.0.0.94) that works with .NET Core! Here is his post on dotnet/sdk#335. Here is a link to the latest beta release

My .travis.yml file looks like:

sudo: required
dist: trusty
language: csharp
solution: MySolution.sln
mono:
  - beta
dotnet: 1.0.3

install:
  - nuget restore MySolution.sln
  - dotnet restore MySolution.sln

script:
  - msbuild /t:Rebuild MySolution.sln
1
votes

Mono DOES support building VS2017 .Net Framework projects as it now uses msbuild.

To get it working on Travis CI is a bit tricky but this should do the trick:

  - wget -q https://packages.microsoft.com/config/ubuntu/14.04/packages-microsoft-prod.deb
  - sudo dpkg -i packages-microsoft-prod.deb
  - wget -q http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/gcc-5-base_5.4.0-6ubuntu1~16.04.9_amd64.deb
  - sudo dpkg -i gcc-5-base_5.4.0-6ubuntu1~16.04.9_amd64.deb
  - wget -q http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.9_amd64.deb
  - sudo dpkg -i libstdc++6_5.4.0-6ubuntu1~16.04.9_amd64.deb
  - wget -q http://security.ubuntu.com/ubuntu/pool/main/i/icu/libicu55_55.1-7ubuntu0.4_amd64.deb
  - sudo dpkg -i libicu55_55.1-7ubuntu0.4_amd64.deb
  - sudo apt-get install apt-transport-https
  - sudo apt-get install -y libicu55
  - sudo apt-get install dotnet-runtime-deps-2.1
  - sudo apt-get install dotnet-runtime-2.1
  - sudo apt-get install aspnetcore-runtime-2.1
  - sudo apt-get install dotnet-sdk-2.1

Basically, you need to manually install the dotnet-sdk manually and all of it's dependencies.

Then simply call msbuild:

  - msbuild /p:Configuration=Release Solution.sln
0
votes

.NET Framework Targeting Pack Nuget Packages

You can now build new style csproj projects with Mono on Linux by adding a NuGet package:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup Label="Build">
    <OutputType>Exe</OutputType>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>

  <ItemGroup Label="Package References">
    <PackageReference 
      Include="Microsoft.NETFramework.ReferenceAssemblies" 
      PrivateAssets="All" 
      Version="1.0.0-preview.2" />
  </ItemGroup>

</Project>

More information can be found on the Microsoft/dotnet GitHub page. At the time of writing it's in preview but I've found that it does work. The only gotcha I discovered is that dotnet test with xUnit projects does not work and is not a supported scenario according to the xUnit author.