Skip to content

Enable Mono 4.0.1+ build / xUnit testing #1129

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

Closed
wants to merge 1 commit into from

Conversation

sushihangover
Copy link

Note: This is for getting libgit2sharp building and running the xUnit test suite on mono 4.0.x+. I am using only mono 4.0.1+ and needed to do this for my own projects, but if there are is no current need, or a different roadmap is in place for vetting mono 4+, you can close it. Thanks.

Note: Githib auto-closed the last pull-request as I bumped the wrong branch from my private repo.

Bump CI build requirements:

  • OS-X : 4.0.2 (latest public MDK package)
  • Linux: 4.0.1 (latest in debian main, non-pinned version)

Added exe wrapper for CustomBuildTasks.dll to allow travis project building/running using xunit runner console with the following:

  • Xamarian Studio v5.9.x+ / MonoDevelop v5.9.x+
  • mdtool (matching version from above's IDE installation)
  • xbuild (from mono 4.0.1+ installation)

xplat building via cmd line or IDE (Xamarin Studio / MonoDevelop)

Build the wrapper for project's custom build tasks:

xbuild Lib/CustomBuildTasks/CustomBuildTasksExe/CustomBuildTasksExe.csproj

Build LibGit2Sharp.dll:

xbuild LibGit2Sharp.Tests/LibGit2Sharp.Tests.cspro

Build and Run xUnit tests:

xbuild LibGit2Sharp/LibGit2Sharp.csproj
cd LibGit2Sharp.Tests/bin/Debug
mono ../../../packages/xunit.runners.1.9.2/tools/xunit.console.exe LibGit2Sharp.Tests.dll

* OS-X : 4.0.2 (latest public MDK package)
* Linux: 4.0.1 (latest in debian main, non-pinned version)

Added exe wrapper for CustomBuildTasks.dll to allow xplat project building with the following:
* Xamarian Studio v5.9.x+ / MonoDevelop v5.9.x+
* mdtool (matching version from above's IDE installation)
* xbuild (from mono 4.0.2+ installation)
@nulltoken
Copy link
Member

Paste from @bording's comment in #1127

"Oh, I think I just figured out what it is you're trying to fix! You're trying to build on mono 4, and the CustomBuildTasks project is still using 3.5, which means the checked in dll is probably blowing up since mono 4 removed the 2.0 assemblies.

In that case, I would think the only thing that needs to be done is update CustomBuildTasks to net4, and then check in the new dll. Everything else should just work without any other changes at that point.

Both of the build tasks brought in via the targets files already work fine cross platform when using mono 3.12, so there shouldn't be any need for all of the workarounds/skipping them going on in this commit once the CustomBuildTasks assembly is built with net4."

@sushihangover
Copy link
Author

I tried just updating the CustomBuildTask.dll that is wired in the repo, but it failed to load under mono's MSBuild target/task assembly load routine and thus the xUnit tests failed to execute. The only way 'I' could get it to work was 1) to use the xUnit console runner and 2) avoid loading the custom build task in mono's 4.0 version of MSBuild, thus I just shell to the wrapper I put on it. Maybe someone else has had success?

@bording
Copy link
Member

bording commented Jun 30, 2015

Since it is working fine in mono 3.12, then I think we'd want to investigate more about what's up with the mono 4 failure vs. bringing all of this other stuff, because there's nothing about mono 4 that should require a more elaborate workaround here.

I do know that xUnit has some issues with mono 4 currently, which is one of the reasons LibGit2Sharp is still targeting 3.12 for now.

@sushihangover
Copy link
Author

NP, I 'assume' it is all related to the xUnit 1.9.x assembly version mismatch in Mono and thus the CI custom msbuild target fails (but I have seen other issues in Mono;s 4.x MSBuild with custom targets, so pointing fingers on xUnit is just an assumption). Using their 1.9.x console runner under Mono 4.0.x works fine and I am unblocked on my projects. I did not change and test the xUnit 4.x version in this project as there are lots of Linux users pinned on Mono 3.x on our projects and thus need them to be able to run our custom git tests and libGit2Sharp based ones, thus we are pinned to xUnit 1.9.x till we freeze our 3.x based releases and move to only mono 4.x based releases...

As i said, you can just close it.

@carlosmn
Copy link
Member

carlosmn commented Jul 1, 2015

The xUnit issues have been fixed in mono, and you can use it with the mono snapshots. We however do not want to move the CI scripts to only run on mono 4, which it looks like this PR is doing. We still very much should support the older mono versions.

@sushihangover
Copy link
Author

Not sure of the libgti2sharp Mono roadmap, but one option is to run two complete CI passes, one on 3.6.0 and one on some version of 4.0.x since 4.0.2.5 is the standard MDK release platform on Windows and OS-X and 4.0.1 is the unpinned version for Linux now.

FYI: Under Mono, we run 6 CI passes on each build for each OS as the Mono code path results in different CI outcomes:
3.12.1 : gets Jit only, LLVM enabled, and AOT.
4.0.2 : gets Jit only, LLVM enabled and pure/full stack AOT.

Note: Our "pure/full stack" AOT requirement under 4.x requires a custom code path for this library (and others) as we AOT the framework, custom assys and the exes.

@nulltoken
Copy link
Member

Not sure of the libgti2sharp Mono roadmap, but one option is to run two complete CI passes

We'd be very open to such a proposal. Would you be interested in tweaking this PR to make this happen?

@sushihangover
Copy link
Author

Sure, let me see what I can get to over the weekend

@carlosmn
Copy link
Member

Superseded by #1300 with testing for 3.x and 4.x versions of mono, with xunit for both.

@carlosmn carlosmn closed this Apr 17, 2016
Sign up for free to 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