-
Notifications
You must be signed in to change notification settings - Fork 466
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix broken Linux CI build on Appveyor #496
Conversation
f90c5d9
to
66d75ea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to simplify and speed this up a bit further, so this will briefly go back to draft status.
eb12875
to
961d227
Compare
102ef67
to
3a9b9b5
Compare
@jonorossi, this should fix our CI and get rid of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stakx Great work. It'll be great to clean up all this old framework mess and then get a cleaner build set up.
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! |
Our CI test run on Linux is currently broken due to a regression in the version of Mono that comes preinstalled in AppVeyor's
Ubuntu
worker 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
net35
target now, rather than later (in a better-fitting PR like #495). Having to give upnet35
is a consequence of us now runningmono
via 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 theFrameworkOverride
hack 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.