weixin_39559277
2021-01-11 09:16 阅读 3

GetAccessControl and SetAccessControl methods missing on System.Threading.Mutex compared to Framework

In .NET Framework, the following methods are available on System.Threading.Mutex:

  • GetAccessControl
  • SetAccessControl

These methods do not exist on System.Threading.Mutex in .NET 5/.NET Core - why?

To my mind, they should at least exist and throw PlatformNotSupportedException, but ideally they would be implemented to work as per Framework.

该提问来源于开源项目:dotnet/runtime

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

10条回答 默认 最新

  • weixin_39880328 weixin_39880328 2021-01-11 09:16

    I believe they exist as extension methods in the System.Theading.AccessControl package.

    https://github.com/dotnet/runtime/blob/adad810e664f53211aed98f0f06b6beeaede180c/src/libraries/System.Threading.AccessControl/ref/System.Threading.AccessControl.cs#L158-L166

    点赞 评论 复制链接分享
  • weixin_39559277 weixin_39559277 2021-01-11 09:16

    Okay, there are two issues here.

    • The first is that in non-Framework versions, these methods were spun off from Mutex into ThreadingAclExtensions, which breaks MSDN docs' redirection when switching between Framework and non-Framework - hence why I was unable to find them.

    For example, if I go to https://docs.microsoft.com/en-gb/dotnet/api/system.threading.mutex.getaccesscontrol?view=netframework-4.8, and then change the "Version" dropdown in the top-left to (say) .NET Core 3.1, I get redirected to https://docs.microsoft.com/en-gb/dotnet/api/system.threading.mutex.getaccesscontrol?view=netframework-4.8&viewFallbackFrom=netcore-3.1 which tells me "The requested page is not available for .NET Core 3.1. You have been redirected to the newest product version this page is available for." - when it should ideally redirect me to https://docs.microsoft.com/en-gb/dotnet/api/system.threading.threadingaclextensions.getaccesscontrol?view=netcore-3.1#System_Threading_ThreadingAclExtensions_GetAccessControl_System_Threading_Mutex_

    Similarly, going to https://docs.microsoft.com/en-gb/dotnet/api/system.threading.threadingaclextensions.getaccesscontrol?view=netcore-3.1#System_Threading_ThreadingAclExtensions_GetAccessControl_System_Threading_Mutex_ and then switching Version to .NET Framework 4.8 sends me to https://docs.microsoft.com/en-gb/dotnet/api/system.threading.threadingaclextensions.getaccesscontrol?view=dotnet-plat-ext-5.0&viewFallbackFrom=netframework-4.8#System_Threading_ThreadingAclExtensions_GetAccessControl_System_Threading_Mutex_ which is a little better, but still not correct.

    Where can I log this for attention?

    • Secondly, the Microsoft.Windows.Compatibility metapackage includes System.Threading.AccessControl - but quite obviously, any code compiled against Framework that uses GetAccessControl/SetAccessControl on Mutex, will not know it actually needs to call into ThreadingAclExtensions instead. Thus, such code fails with MissingMethodException if run in a Core/5.0 project, even with Microsoft.Windows.Compatibility installed - which somewhat defeats the purpose of the latter.

    Is this something that the .NET team can/will fix? Should I file it as a separate issue, if so where?

    点赞 评论 复制链接分享
  • weixin_40005887 weixin_40005887 2021-01-11 09:16

    you can file issues against docs in this repo: https://github.com/dotnet/dotnet-api-docs

    For the latter question, I am not sure how that could be fixed. Maybe knows the history here, it seems to go way back.

    点赞 评论 复制链接分享
  • weixin_39603778 weixin_39603778 2021-01-11 09:16

    All of the AccessControl types were moved higher up in the stack since they were windows specific. The extension methods were designed to offer source compatibility for folks moving from .NETFramework to .NETCore (or .NETStandard). We cannot forward to extension methods from the lower-stack types (no such technology exists), and the members cannot exist on the lower stack types without bringing all of the AccessControl types down in order to match the method signature, even if we wanted them to throw PlatformNotSupportedException.

    any code compiled against Framework that uses GetAccessControl/SetAccessControl on Mutex, will not know it actually needs to call into ThreadingAclExtensions instead

    Compiling for .NETFramework and running in .NETCore is not a perfect thing and in most cases the IDE will warn you when you try to do this. Even with Microsoft.Windows.Compatibility, it will only work when the types or members exist in .NETCore. That's not the case here: these members do not exist and these exceptions are by design.

    Microsoft.Windows.Compatibility does enable compiling a .NETStandard library and using these APIs. It will do the right thing when run in both .NETFramework and .NETCore. The extension methods were added via the Compatibility package to .NETFramework. If compiling for NETStandard works for you that would avoid this. If you can't compile against .NETStandard nor .NETCore, then you could directly invoke the static extension methods which would also work everywhere.

    The only real way to fix this is to push AccessControl types down, all the way to CoreLib. Perhaps folks would have more of an appetite for this now that we have the platform compatibility analyzer. , what do you think?

    点赞 评论 复制链接分享
  • weixin_39918043 weixin_39918043 2021-01-11 09:16

    I think the Windows-specific ACLs should stay where they are. As you have said, the compatibility with .NET Framework is always only going to be best effort.

    点赞 评论 复制链接分享
  • weixin_39918043 weixin_39918043 2021-01-11 09:16

    Perhaps folks would have more of an appetite for this now that we have the platform compatibility analyzer.

    I do not think platform compatibility analyzers should be used as an excuse for faulting large OS-specific technology blocks into CoreLib.

    点赞 评论 复制链接分享
  • weixin_39559277 weixin_39559277 2021-01-11 09:16

    If compiling for NETStandard works for you that would avoid this. If you can't compile against .NETStandard nor .NETCore, then you could directly invoke the static extension methods which would also work everywhere.

    Unfortunately I do not have access to the source code - this is a third-party DLL from a Large ERP Company (a large consumer/user of Microsoft Azure) that refuses to compile their C# code for anything newer than .NET Framework 4.5.2 (they have directly informed us that they have no interest in supporting anything newer than Framework going forward). The company I work for writes integrations for said Large ERP Company's products, and obviously we'd like to use tech that's not half a decade old. Thus I decided to test Large ERP Company's DLL in a .NET 5 project in the vain hope it would work as-is, and it did - until I hit this particular roadblock.

    So this is unfortunate, but I understand the reasons why you've split these methods out from the BCL, and honestly agree with it. I just wish that Microsoft would put the appropriate amount of pressure on its partners to ditch Framework.

    点赞 评论 复制链接分享
  • weixin_40005887 weixin_40005887 2021-01-11 09:16

    Thanks for the update. You're aware, but clarifying for anyone else: building for .NET Standard does not mean losing support for .NET Framework: it simply enables it to run on either.

    点赞 评论 复制链接分享
  • weixin_39559277 weixin_39559277 2021-01-11 09:16

    Thanks for the update. You're aware, but clarifying for anyone else: building for .NET Standard does not mean losing support for .NET Framework: it simply enables it to run on either.

    I should've said "ditch versions of Framework that are not compatible with .NET Standard 2.0". Yes I know that Standard 1.x exists, but its API surface is so small compared to 2.0 that it rarely makes sense to target anything below 2.0.

    The fact that Microsoft declares and supports Framework 4.5.2 as the minimum supported version is really what is holding things back, because it gives enterprise customers like Large ERP Company an excuse to never upgrade. If we could get that 4.5.2 bumped to 4.8 it would make such a huge difference to adoption and getting enterprises into 2019 (4.8 release year) vs 2014 (4.5.2 release year). It's not as if you guys don't have an upgrade guide for this very scenario. Right now I'd even be happy with the minimum being 4.6.1 which is the first (nominally) .NET Standard 2.0-compliant version.

    点赞 评论 复制链接分享
  • weixin_40005887 weixin_40005887 2021-01-11 09:16

    As you say, nominally: the docs note that there are issues with .NET Standard 2.0 support below 4.7.2.

    点赞 评论 复制链接分享

相关推荐