Comments (16)
Which version of System.IO.Abstractions did you use?
Does this exception only arise in this specific environment?
from system.io.abstractions.
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.
from system.io.abstractions.
is the strack trace and description from the beginning the same?
from system.io.abstractions.
Yes, there were no change in call stack or behavior when I upgraded from 1.4.0.83 to 1.4.0.84.
from system.io.abstractions.
I just encountered this issue using 1.4.0.86 and Mono 3.6.1
from system.io.abstractions.
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.
from system.io.abstractions.
I'll take a look at it later, thanks.
from system.io.abstractions.
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.
from system.io.abstractions.
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?)
from system.io.abstractions.
@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
from system.io.abstractions.
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.
from system.io.abstractions.
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:
)
from system.io.abstractions.
@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)
from system.io.abstractions.
...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.
from system.io.abstractions.
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 😛
from system.io.abstractions.
The original goal of this project was just to provide IAllTheThings
. Then, because manually mocking file system interaction calls with something like NSubstitute quickly gets boring, I started on MockFileSystem
. As long as MockFileSystem
doesn't touch the disk, and it vaguely acts kind of sort of maybe like a file system might, then I don't think it matters too much how the internals work (like calling Path.DirectorySeparatorChar
).
from system.io.abstractions.
Related Issues (20)
- Async options for all actions HOT 1
- IFile.Open(Read) cannot be mocked with NSubstitute anymore due to System.IO.Abstractions.FileSystemStream HOT 8
- MockFileSystem: IFile.GetLastWriteTimeUtc may return wrong last write time after calling IFileInfo.Open HOT 2
- BinaryFormatter becomes obsolete -> Remove it with .NET 8.0 HOT 2
- MockPath.GetFullPath does not match windows behavior. HOT 4
- IDirectoryInfoFactory.Wrap loses part of absolute path when used with MockFileSystem HOT 4
- PathVerifier fails on whitespace filename under Linux and .NET Core HOT 1
- Creating new MockFileInfo thinks file exists when it actually does not. HOT 3
- Microsoft Fakes does not generate Fakes namespace for System.IO.Abstractions interfaces HOT 1
- I want to step out of this project HOT 13
- Providing mocks as and when necessary HOT 4
- Allow selection of os dependent FS semantics HOT 3
- Clearning the `Directory` flag causes a directory to be turned into a regular file HOT 1
- `FlushAsync` doesn't update file contents HOT 3
- FileStreamWrapper breaks patternmatching type testing HOT 5
- MockFileSystem.Directory.CreateDirectory should throw IOException if conflicting file exists HOT 2
- Signature missing in the dll HOT 8
- FileInfoFactory and DirectoryInfoFactory Wrap implementations don't match the interface for nullability HOT 2
- IFileSystemInfo.ResolveLinkTarget throws exception instead of returning null if the path is not a link HOT 3
- Creation of the default "temp" directory in MockFileSystem should have a toggle HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from system.io.abstractions.