Fix broken Linux CI build on Appveyor #496
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stakx
force-pushed
the
ci
branch
20 times, most recently
from
f90c5d9
to
66d75ea
Compare
stakx
commented
May 2, 2020
stakx
force-pushed
the
ci
branch
6 times, most recently
from
eb12875
to
961d227
Compare
stakx
force-pushed
the
ci
branch
2 times, most recently
from
102ef67
to
3a9b9b5
Compare
|
@jonorossi, this should fix our CI and get rid of |
4 tasks
The new .NET CLI (`dotnet`) cannot build projects that target `net35`, because it cannot locate the required reference assemblies. Since we're planning to drop support for .NET Framework 3.5 anyway, it is not worth finding a workaround for this problem--let's just remove that target framework now. References: * dotnet/msbuild#1333
We no longer mention .NET Framework 3.5 support in the docs, let's do likewise for Silverlight.
There are additions to the public API for `netstandard1.x`, which is due to some `#if`s that were previously too restrictive. (`ISet<T>` is not just supported on .NET 4.x, but on anything newer than .NET 3.5.)
Now our build no longer relies on Mono to provide reference assemblies for the .NET Framework, and we no longer need to know where they are located.
`dotnet build` restores packages by default, so explicitly restoring packages shouldn't be necessary. Also, there's no more need to build individual projects; `dotnet` can build whole solutions.
This lets us choose which version of Mono to use without having to install it. This is important because the version currently preinstalled on App- Veyor has a regression that breaks our build, and installing another Mono version on AppVeyor is both slow and error-prone.
|
Rebased, and removed the Silverlight thingy, @jonorossi, I'll merge this tonight (i.e. in a few hours' time) if nothing else comes up. |
|
Sounds good to me. 5.0 here we come! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our CI test run on Linux is currently broken due to a regression in the version of Mono that comes preinstalled in AppVeyor's
Ubuntuworker images.After much trial and error, I think I've found a reasonable compromise to get CI working again. I'm calling it a compromise because if we want to keep our CI build script reasonably simple, we need to give up our
net35target now, rather than later (in a better-fitting PR like #495). Having to give upnet35is a consequence of us now runningmonovia Docker during the Linux CI test run (so that we can choose its version without ending up in an uninstall/install orgy). It would be a little nonsensical to run Mono via Docker on the one hand, but OTOH still rely on a locally installed Mono for the .NET Framework reference assemblies. The latter can now be got from an official NuGet package (which is a much neater solution than theFrameworkOverridehack used so far); that however doesn't include any reference assemblies for .NET 3.5.All of this isn't really a problem, since we were going to stop supporting .NET 3.5 anyway—we just have to do that now.
This PR also includes a few minor changes to our CI build scripts which aren't strictly necessary, but make it a wee bit simpler or more up-to-date.