据我所知,这里有两种选择:
>使用this issue中所述的FrameworkPathOverride环境变量指向它们.
>将Travis构建限制为仅针对.NET Core构建.根据我的经验,这简单得多.
这是Noda Time .travis.yml文件,当我可以迁移时,我将在Noda Time使用它 – 至少可以说它是初步的,但它确实构建了……
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
关于此的几点说明:
>与早期的SDK不同,我们现在需要单独恢复每个项目 – 顶级没有大的“dotnet恢复”:(
>当我没有在dist上运行时,我感到很惊讶:xenial,但事实并非如此. (它声称环境不支持.NET Core.)我猜这会改变.
>我们正在使用NUnit,目前在新SDK中测试的唯一方法是使用NUnitLite,因此运行dotnet运行测试
>我有点惊讶我不能只指定dotnet运行的目录名称(根据dotnet restore和dotnet build),但这似乎是事情的方式.我会找一个bug报告……
在任何一种情况下,我都建议使用基于Windows的CI构建来检查所有内容是否在Windows上构建和运行(理想情况下测试您支持的每个框架).