reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rogan Carr <rogan.c...@gmail.com>
Subject Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Date Wed, 02 Aug 2017 22:43:14 GMT
Hi All,

I did some more investigation on Org.Apache.REEF.IO, and it looks like we
have breaking changes in the FileInfo and DirectoryInfo APIs if we want to
make it .NET Standard 2.0 compatible.

That said, the APIs can be easily made to be .NET Core 2.0 compatible quite
easily. (See [1] and [2] for the API documentation.)

What do you all think? Is .NET Core 2.0 good enough or do we need strict
.NET Standard 2.0 compliance?

Best,
Rogan

References:
See the "Extension Methods" section in the following pages-- these are .NET
Core 2.0 compliant extensions, but not .NET Standard 2.0 compliant.
[1] FileInfo .NET Standard 2.0
https://docs.microsoft.com/en-us/dotnet/api/system.io.fileinfo?view=netstandard-2.0
[2] DirectoryInfo .NET Standard 2.0
https://docs.microsoft.com/en-us/dotnet/api/system.io.directoryinfo?view=netstandard-2.0

On Thu, Jul 20, 2017 at 6:14 PM, Rogan Carr <rogan.carr@gmail.com> wrote:

> Hi Saikat,
>
> It looks like the DirectorySecurity and FileSecurity objects are
> compatible: https://www.nuget.org/packages/System.IO.FileSystem.
> AccessControl/
>
> This means that we don't have to change the public APIs for .NET Standard
> 2.0.
>
> The issue is that the DirectoryInfo.Create() method can't take a
> DirectorySecurity object, only a string for the name. I still have to
> investigate to see if we can create workarounds for these APIs, but I
> imagine we can get a bit creative here.
>
> Best,
> Rogan
>
> On Thu, Jul 20, 2017 at 5:56 PM, Saikat Kanjilal <sxk1969@gmail.com>
> wrote:
>
>> Hey Rogan,
>> Given that I was working on this issue and remember running into this I
>> was wondering what the equivalent of DirectorySecurity is in .net 2.0.  I
>> would not recommend that we keep 2 APIs with flags, it makes the
>> architecture messy to debug and maintain. My 2 cents for what it's worth,
>> we can discuss offline as well.
>> Regards
>>
>> Sent from my iPhone
>>
>> > On Jul 20, 2017, at 5:48 PM, Rogan Carr <rogan.carr@gmail.com> wrote:
>> >
>> > Hi All,
>> >
>> > I have a correction to make. A colleague pointed out that the
>> FileSecurity
>> > and DirectorySecurity objects are .NET Standard 1.3 compliant, so we can
>> > return these -- no issues with our public interface.
>> >
>> > Internally, it looks like the only incompatibility is how we use these
>> > objects, but that should be a doable change.
>> >
>> > Best,
>> > Rogan
>> >
>> >> On Thu, Jul 20, 2017 at 5:10 PM, Rogan Carr <rogan.carr@gmail.com>
>> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> In investigating REEF-1584, I ran into an interesting compatibility
>> issue.
>> >>
>> >> IFileSystemInfo and IDirectoryInfo have public contracts that return
>> >> FileSecurity and DirectorySecurity objects, which are not ".NET
>> Standard
>> >> 2.0" compliant.
>> >>
>> >> The APIs in REEF are not used internally, However, I cannot be sure
>> that
>> >> they are not used outside of REEF.
>> >>
>> >> I have two questions:
>> >>
>> >> 1) Does anybody know any concrete use cases that hit these APIs?
>> >> 2) What process should we take to update this library, seeing as how we
>> >> may not be able to get rid of this API, but can't take it to .NET
>> Standard?
>> >>    - One option is to use build flags that keep this interface for
>> >> Windows, and a new interface for .NET Standard 2.0.
>> >>
>> >> Best,
>> >> Rogan
>> >>
>> >> [1] https://issues.apache.org/jira/browse/REEF-1584
>> >>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message