FileStreamWrapper breaks patternmatching type testing about system.io.abstractions HOT 5 OPEN

Can we improve the visibility of this breaking change in the changelog for version 18?

@vbreuss I added this to the release notes: https://github.com/TestableIO/System.IO.Abstractions/releases/tag/v18.0.1

from system.io.abstractions.

@cryolithic :
I am afraid, that we don't have any options to resolve your issue.

• We intentionally changed the return type to a custom Stream class due to #779.
• Directly using FileStream is not possible, as the class is sealed and directly affects the file system, so we cannot overwrite/replace it's functionality in the test class.
  So in order to work with Streams we had to replace them with a custom wrapper
• Using an interface as in other factory classes (e.g. IFileStream) instead would also not help in your case, as FileStream does not implement it and we would no longer return a Stream at all...

What do you want to achieve with this test of yours?

from system.io.abstractions.

The method in question acts as a factory (implementation is a bit more complex, but the details shouldn't matter). It accepts a Stream, and creates a StorageProvider to match the specifics of the stream type as we have different behaviour for a FileStream vs say a MemoryStream.

I worked around it in my code, but any libraries that make a similar check will break when using Abstractions.

from system.io.abstractions.

@cryolithic:
Unfortunately I underestimated this impact in #906 and didn't mark it explicitely as breaking change in itself, so the major version got bumped due to the refactoring in general, but this change is not explicitely mentioned in the changelog.

I don't have any idea for a workaround that doesn't involve this breaking change. Do you?

@fgreinacher:
Can we improve the visibility of this breaking change in the changelog for version 18?

from system.io.abstractions.

I'll go ahead close this. Feel free to reopen/comment if anything else can be improved.

from system.io.abstractions.