Skip to content

Conversation

@Therzok
Copy link
Member

This bumps the build tasks to .NET 4.0 for preliminary support of building libgit2sharp in Mono 4. I still don't know if XUnit 2.0 works on Mono 4, but XUnit 1.9.2 won't work because pre-4.0 profiles were removed.

@TherzokTherzok closed this Apr 27, 2015
@TherzokTherzok deleted the therzok/mono4 branch April 27, 2015 13:12
@Therzok
Copy link
MemberAuthor

Forgot I did this as part of xunit 2.0 port.

@TherzokTherzok restored the therzok/mono4 branch April 28, 2015 09:04
@TherzokTherzok reopened this Apr 28, 2015
@Therzok
Copy link
MemberAuthor

Hey @nulltoken, can we please have this merged it can be built with mono4? Tests don't matter for now.

@bording
Copy link
Member

If this does get merged in, I'll be sure to account for this in #984, because I've added a task to CustomBuildTasks there.

CustomBuildTasks is another good candidate for moving out of the main repo and bringing it in via NuGet. We'd be able to stop checking in the dll that way!

@Therzok
Copy link
MemberAuthor

Just a minor notice: All Linux travis CI builds will fail. Mono package is now 4.0, and xunit 1.9.2 uses .NET 2.0 profile, which has been removed.

Not sure if XUnit 2.0 works there, but worth a try, probably.

@nulltoken
Copy link
Member

Hmrpf... Well, we've got quite a conundrum here.

As far as I understand it, the current situation is

@Therzok@bording@carlosmn I'd really like to keep on supporting Mono 3.6 for some time while still allowing LibGit2Sharp to work with Mono 4.0. If we cannot think of a quick solution, I wonder if the safest short-term solution wouldn't be to pin the Linux builds to Mono 3.12.1 while we try to figure out something... Thoughts?

@nulltoken
Copy link
Member

I wonder if the safest short-term solution wouldn't be to pin the Linux builds to Mono 3.12.1 while we try to figure out something..

Eventually did this with #1036

Now we can take a little bit time to think about the dual 3.6/4.0 Mono support

@bording
Copy link
Member

Forcing the CI builds to keep away from 4.0 definitely seems like the best course of action for now.

If/when xUnit works with Mono 4.0, I'm guessing that means it's not likely to work with 3.12 or earlier.

If we end up with a with 1.9.2/3.122.0/4.0 split, then that gets pretty messy. The only thing that comes to mind would be having multiple test projects in the repo, one using 1.9.2 and one using 2.0, and share as much of the test code as possible between them. Then with some CI script magic we could build/run the appropriate test project for each platform.

That's even assuming the changes to get the test project working with 2.0 wouldn't completely break 1.9.2 support, which from what I've seen probably isn't a safe assumption.

If that is possible, it's still going to be maintenance nightmare though. 😦

The bindings are already here, and this also allows us to build both on mono 3 as well as mono 4, which dropped pre-4.0 assemblies from the install.
@nulltoken
Copy link
Member

Rebased

nulltoken added a commit that referenced this pull request Jul 3, 2015
@nulltokennulltoken merged commit 00478e2 into vNextJul 3, 2015
@nulltokennulltoken deleted the therzok/mono4 branch July 3, 2015 06:07
@nulltokennulltoken added this to the v0.22 milestone Jul 3, 2015
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Therzok@bording@nulltoken