NullReferenceException when instantiating MockFileSystem in Mono/Mac

[sisve]

Environment

• Xamarin Studio 4.3.4
• Mono 3.4.0

Reproduction

new MockFileSystem()

Stacktrace

System.IO.Abstractions.TestingHelpers.MockPath.GetFullPath (path="C:\\Foo\\Bar")
System.IO.Abstractions.TestingHelpers.MockFileSystem.FixPath (path="C:\\Foo\\Bar")
System.IO.Abstractions.TestingHelpers.MockFileSystem..ctor (files=(null), currentDirectory="C:\\Foo\\Bar")
System.IO.Abstractions.TestingHelpers.MockFileSystem..ctor ()

Debugging shows that the MockFileSystem constructor calls FixPath which in turns calls this.pathField.GetFullPath (implemented by MockPath.GetFullPath). There's a call to this.mockFileDataAccessor.Directory.GetCurrentDirectory in GetFullPath which fails since MockFileSystem.Directory is null at this point.

[manne]

Which version of System.IO.Abstractions did you use?
Does this exception only arise in this specific environment?

[sisve]

I've just updated to 1.4.0.84 using nuget and still experience the same problem. I get it running unit-tests within Xamarin Studio. The tests works in Visual Studio and in our Windows-based TeamCity-installation. I'm mentioning that our buildserver is windows-based since I do not know if this error is due to mac- or mono-environment.

[manne]

is the strack trace and description from the beginning the same?

[sisve]

Yes, there were no change in call stack or behavior when I upgraded from 1.4.0.83 to 1.4.0.84.

[nosami]

I just encountered this issue using 1.4.0.86 and Mono 3.6.1

[tathamoddie]

Hey folks. Repo owner here. I don't use Mono, or have a Mac, and am unlikely to configure a Mono environment any time soon. Thus, hard to debug. I'll be happy to accept any pull request which doesn't break Windows, preferably with a unit test to make sure I don't break Mono again in the future.

[nosami]

I'll take a look at it later, thanks.

[nosami]

This isn't going to be an easy fix. I've wrestled with this problem in the past with my OmniSharp project. There seems to be a few issues here.

• GetPathRoot returns an empty string when passed a Windows path on a Unix system.
• Nearly all tests are failing on Unix due to above problem and the wrong DirectorySeparatorChar being used (the tests use backslashes but Unix file separator is /).
• To be able to replicate Unix issues on Windows you'd also need to replicate the way GetPathRoot behaves on linux. I'm not 100% sure, but it might be necessary to use some of the Mono code in your project to test Unix issues.
• UNC paths etc just don't exist on Unix

I would love to be able to use a MockUnixFileSystem on Windows and vice versa. I'm not sure how much work is required for this, but at a minimum, we'd need to be able to specify the DirectorySeparatorChar in the constructor. I think the same applies for MockPath.

Ideally I'd like to see a MockWindowsFileSytem and a MockUnixFileSystem. How do you feel about that as it's quite a major change? I can help you get CI setup on Travis too if you'd like to automate testing on either Linux or OSX.

[tathamoddie]

So, easy, right?

https://twitter.com/arialdomartini/status/478276662820614145/photo/1

Is the need for this popping up due to K? I don't understand the Xamarin scenario, as most mobile platforms don't expose a real file system so much as isolated storage as far as I'm aware.

Extending my earlier remark, I don't have a need for this myself, so I can pretty much guarantee I'll never get to it. That being said though, I will wholeheartedly support any effort that extends the usability of the library, without compromising Windows support. That would mean a) accepting any changes into the official package so we don't have to fork and b) contributing to whatever is required to support TravisCI (I assume we'll need to host it somewhere, which will cost Azure credits, which I'm happy to supply).

My only other hesitation is that the purpose of the library remains focussed around testable file system access, and not an entire in-memory file system implementation. This proposal seems within the spirit of that, however I'm generally wary of how far the testing helpers are starting to stretch, and would probably get concerned if MockUnixFileSystem started to support things like the eccentricities of Unix file permissions. (Or maybe that's the point now?)

[aaronpowell]

@tathamoddie I'm not sure how overly useful this might be in the K world as it looks like they started to write their own FS with mocks - https://github.com/aspnet/FileSystem/tree/dev/src/Microsoft.AspNet.FileSystems

[nosami]

My personal need is for (OmniSharp)[https://github.com/nosami/Omnisharp] which needs to run on Windows and Unix. I run my tests on both TeamCity for Windows and TravisCI for Unix. My tests contain a mixture of Windows and Unix tests and I run all tests on both environments. I also need to emulate a Windows file system in production code when I'm on Unix to handle .net solution files. I have a whole range of hacks to accomplish this and I was hoping that this project might be able to help me out here.

I guess that this would be useful for anyone writing cross platform code.

When I saw that this project didn't work on Unix, it reminded me of all the problems I've had to make things work in my own project.

It would have been nice if I could have made a simple patch and a test for this.. but how do you test Unix behaviour on Windows and vice versa? The alternatives are :-

• Test on both systems with conditional compilation - only test Windows behaviour on Windows and Unix on Unix. Travis is free by the way for OSS projects.
• Use some kind of abstraction to build up the paths used by the tests. When ran on Unix, unix paths would be generated

Neither of those options sound ideal. I'm sure that my proposal could get a little tricky. It just seems to me that there is a need for this that hasn't been met yet.

[aaronpowell]

I wonder if instead of hard-coding a default mock file of c:\Foo\Bar it was actually string.Join(Path.DirectorySeparatorChar, "foo", "bar"), although I don't know how to represent the default volume (aka C:)

[nosami]

@aaronpowell I was thinking of something along those lines when I said 'use some kind of abstraction'. On top of that though, you'd also need to change everywhere in the test suite where a Windows path had been used (if you wanted the tests run on *nix)

[nosami]

...And... this would need changing https://github.com/tathamoddie/System.IO.Abstractions/blob/95e8c9fd7308fdc19b1f244efc78c9e9b17d693f/TestingHelpers/MockPath.cs#L47 as '/' is returned from GetPathRoot for a path such as /foo/bar . Probably quite a few other things that would need changing too. I got to around 50 failing tests (down from 200+) by just hacking away on the code without any regard to keeping the code working for Windows.

[aaronpowell]

I wonder (and this is probably something @tathamoddie would be better at answering) would there be something wrong with using Path.DirectorySeparatorChar in the mocks (and core) as it kind of seems to be against the idea of using an abstraction if you just take a dependency on the original code anyway 😛