Multi-target-framework support

[rkoeninger]

There are a lot of #if NET40 ... #endif found in the code. These surround IO functions that are available in .NET Framework >= 4.0, but were not available in .NET Standard 1.0 < 2.0.

Some of these are now available in .NET Standard 2.0, but are not supported by the library, so the directive could be changed to #if ! netstandard1.4 or whatever the exact naming would be.

Framework-specific methods could be made adjacent, or event moved to their own file using partial classes. For example, remove the 4 methods in #if's from MockFileInfo.cs and add a file called MockFileInfo.net40.cs containing something like this:

#if NET40

namespace System.IO.Abstractions.TestingHelpers
{
    public partial class MockFileInfo
    {
        public override void Decrypt() { ... }
        public override void Encrypt() { ... }
        public override FileInfoBase Replace(string x, string y) { ... }
        public override FileInfoBase Replace(string x, string y, bool z) { ... }
    }
}

#endif

Not sure what the name would be if it was for net40 and netstandard2.0, or not for netstandard1.4, however you represent it. Wouldn't want to have 2 separate files or blocks with the same thing in it.

Need to do a survey of methods and see what's supported in netstandard2.0 compared to netstandard1.4 and net40. Might be some in netstandard2.0 but not net40. look at the diff files here.

---

Don't know if this is an issue, but the libraries are build for net40;netstandard1.4;netstandard2.0;, but the TestHelpers.Tests project targets net40;netcoreapp2.0, leaving out Core 1.4. Brief reading makes it sound like all 3 should target standard instead of core, since all 3 are libraries?

[fgreinacher]

I don't like moving TFM-specific stuff to separate files because that quickly gets out-of-control, as you already noticed for the !NETSTANDARD1.4 case.

What do you think of introducing "feature defines" in the project file and then using those in the sources?

It would look like something like this in the project file:

<PropertyGroup>
   <DefineConstants Condition="'$(TargetFramework)' != 'netstandard1.4'">$(DefineConstants);FEATURE_FILE_ENCRYPTION</DefineConstants>
</PropertyGroup>

And in the sources:

namespace System.IO.Abstractions.TestingHelpers
{
    public class MockFileInfo
    { 
        // ...

#if FEATURE_FILE_ENCRYPTION
        public override void Decrypt() { ... }
        public override void Encrypt() { ... }
#endif 
    }
}

[rkoeninger]

We'd have to do a survey, but I think in some cases, it's just particular overloads (example) that's only supported in some target frameworks, not a whole piece of functionality, but I do like your approach with named defines.

Another thing to consider is that support for these things doesn't change regularly. If something is or isn't supported in a particular target, there's no need to adapt to changes in support for that target. Just new targets.

In that same example, you see #if NET40 || NETSTANDARD2_0 - it would be annoying to have to go back through and add || NETSTANDARD2_5 to that, but it would also be annoying to have FEATURE_SPECIFIC_OVERLOAD_OF_SPECIFIC_METHOD.

I don't see a pretty solution to this.

[fgreinacher]

What’s better with the feature defines is that they are either there or not there, while when you ifdef on TFMs you always have to make sure you handle all of their combinations somehow. And then it’s easy to make mistakes when you add a new TFM.

[304NotModified]

What do you think of introducing "feature defines" in the project file and then using those in the sources?

I think this would be an improvement 👍

[fgreinacher]

This problem is mostly gone with #540