Building VS 2017 MSBuild csproj Projects with Mono on Linux

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?

Jon Skeet
people
quotationmark

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).

people

See more on this question at Stackoverflow