-
Notifications
You must be signed in to change notification settings - Fork 899
All unit tests fail because of Mono.Unix.UnixPath in BuildPath #1040
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
Conversation
This isn't about checking whether we're on Mono, it's about figuring out the actual path to the temporary directory on OS X. We would have to do the same under CoreCLR. Having Mono.Posix on Windows is quite odd. It'd be unfortunate if we weren't able to reliably detect whether we can use it. |
I tried to track down where it comes from, and as far as I can tell its from GtkSharp ( After uninstalling this everything runs fine again. I'm assuming this is something that is left behind from having Xamarin installed for Visual Studio. |
Ah, yes, Xamarin Studio puts some assemblies in the GAC. Sadly, I haven't had time to look at working around it and nuget-ing the assemblies. |
That's very unfortunate. We will have to add a check for the OS as well before we try to use Mono.Posix in that case. |
@sitereactor Nice catch! IIRC, Could you check if combining this test would solve the issue? |
In my other xplat projects, I also have to use Mono.Posix only when in Mono/Unix (depends on the use case). The way I always do it is that I put the Mono.Posix dependent functionality in a separate function and the Windows functionality in yet a separate function, something like this: void public DoSomething()
{
if (RuntimeSupport.IsRunningOnUnix())
DoSomethingMono();
else
DoSomethingOnWindows();
} The only calls into Mono.Posix are coming in from This, in turn means that the When on Linux/Mac, Mono.Posix is part of the "package", e.g. part of Mono, and there's never a chance of not finding it or calling into the wrong (too old one) that you packaged yourself... |
@damageboy I've pushed something along your proposal. /cc @jamill I've tried to load the type in a slightly different way in order to not be tied to a specific version of the assembly. |
Grmpf. Something went wrong Travis Mac OS X build log states
This should rather be Could a good soul running on this platform could take a look at and find out where I messed up, please? |
Pretty sure that path is where mono puts Shadow Copy stuff. Try adding ShadowCopy="false" to |
@bording Build in progress... |
@bording Didn't help. Still getting
|
😦 Sorry, thought that might be the solution. I'll try and take a look at this tonight then to see what's going on. |
Aha, the problem is with the I noticed that the It's not showing up. |
And, I think I know why. Both About to push a change to confirm. |
Ok, so that did fix the problem with it never calling Now it's failing on both of them because it doesn't like how you're trying to load the Mono.Posix assembly:
|
|
And there we go, green all around! 🎉 |
@bording Thanks for the help! Just removed some code duplication on top of it. Good to go? |
👍 |
All unit tests fail because of Mono.Unix.UnixPath in BuildPath
@sitereactor Nice report, Sir! Thanks a lot for this ✨ |
Published as NuGet pre-release package |
I just rebased my fork with latest from the
vNext
branch and hit an issue, which seems to be directly related to PR #1018 - all unit tests fail with the following exception:I'm running on Windows 8.1 and VS2013 and the
var unixPath = Type.GetType("Mono.Unix.UnixPath, Mono.Posix, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756");
(found here) type is actually not null even though I'm not running *nix. I actually don't know what addedMono.Unix.UnixPath
to my GAC, but its obviously causing problems.It was mentioned in #1018 that
Mono.Runtime
was used elsewhere to check if "We're running on top of .Net", and changing the type actually makes the unit tests runnable again.