You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@reef.apache.org by Rogan Carr <ro...@gmail.com> on 2017/07/21 00:10:20 UTC
IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
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
Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Posted by Rogan Carr <ro...@gmail.com>.
Hi Markus,
Thanks for the clarity! I'll draft up a solution for Org.Apache.REEF.IO
that builds under these two TargetFrameworks.
Best,
Rogan
On Wed, Aug 2, 2017 at 4:22 PM, Markus Weimer <ma...@weimo.de> wrote:
> .NET Core 2 and .NET Framework 4.6 is what we target for REEF 0.17, I
> believe. If we can get there with .NET Standard, that is great. If
> not, I believe it is fine if we produce DLLs and NuGets targeting
> these two .NET implementations directly.
>
> Markus
>
> On Wed, Aug 2, 2017 at 4:05 PM, Rogan Carr <ro...@gmail.com> wrote:
> > Clarification: What I mean by .NET Core 2.0 compliant, I mean in addition
> > to .NET Framework 4.5.1.
> >
> > On Wed, Aug 2, 2017 at 3:43 PM, Rogan Carr <ro...@gmail.com> wrote:
> >
> >> 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 <ro...@gmail.com>
> wrote:
> >>
> >>> Hi Saikat,
> >>>
> >>> It looks like the DirectorySecurity and FileSecurity objects are
> >>> compatible: https://www.nuget.org/packages/System.IO.FileSystem.
> AccessCo
> >>> ntrol/
> >>>
> >>> 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 <sx...@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 <ro...@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 <ro...@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
> >>>> >>
> >>>>
> >>>
> >>>
> >>
>
Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Posted by Markus Weimer <ma...@weimo.de>.
.NET Core 2 and .NET Framework 4.6 is what we target for REEF 0.17, I
believe. If we can get there with .NET Standard, that is great. If
not, I believe it is fine if we produce DLLs and NuGets targeting
these two .NET implementations directly.
Markus
On Wed, Aug 2, 2017 at 4:05 PM, Rogan Carr <ro...@gmail.com> wrote:
> Clarification: What I mean by .NET Core 2.0 compliant, I mean in addition
> to .NET Framework 4.5.1.
>
> On Wed, Aug 2, 2017 at 3:43 PM, Rogan Carr <ro...@gmail.com> wrote:
>
>> 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 <ro...@gmail.com> wrote:
>>
>>> Hi Saikat,
>>>
>>> It looks like the DirectorySecurity and FileSecurity objects are
>>> compatible: https://www.nuget.org/packages/System.IO.FileSystem.AccessCo
>>> ntrol/
>>>
>>> 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 <sx...@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 <ro...@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 <ro...@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
>>>> >>
>>>>
>>>
>>>
>>
Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Posted by Rogan Carr <ro...@gmail.com>.
Clarification: What I mean by .NET Core 2.0 compliant, I mean in addition
to .NET Framework 4.5.1.
On Wed, Aug 2, 2017 at 3:43 PM, Rogan Carr <ro...@gmail.com> wrote:
> 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 <ro...@gmail.com> wrote:
>
>> Hi Saikat,
>>
>> It looks like the DirectorySecurity and FileSecurity objects are
>> compatible: https://www.nuget.org/packages/System.IO.FileSystem.AccessCo
>> ntrol/
>>
>> 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 <sx...@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 <ro...@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 <ro...@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
>>> >>
>>>
>>
>>
>
Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Posted by Rogan Carr <ro...@gmail.com>.
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 <ro...@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 <sx...@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 <ro...@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 <ro...@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
>> >>
>>
>
>
Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Posted by Rogan Carr <ro...@gmail.com>.
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 <sx...@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 <ro...@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 <ro...@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
> >>
>
Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Posted by Saikat Kanjilal <sx...@gmail.com>.
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 <ro...@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 <ro...@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
>>
Re: IFileInfo and IDirectoryInfo Interfaces aren't .NET Standard 2.0 Compliant
Posted by Rogan Carr <ro...@gmail.com>.
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 <ro...@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
>