weixin_39964528
2021-01-11 10:53 阅读 6

Static method Mutex.TryOpenExisting(String, MutexRights, Mutex) is not available in .NET Core

-a commented on Wed Jan 22 2020

We weren't able to migrate our WPF app to .NET Core 3.1 because MutexRights wasn't available. Hope it gets implemented soon.

Unsupported (per Portability Analyzer): M:System.Threading.Mutex.TryOpenExisting(System.String,System.Security.AccessControl.MutexRights,System.Threading.Mutex@)

commented on Thu Jan 23 2020

This requests is not WPF-specific and probably belongs to corefx (now in the dotnet/runtime repo)

That said as far as I can tell MutexRights still exists and is public. The TryOpenExisting method seems to have moved and the functionality now be covered by MutexAcl.Create or Mutex.OpenExisting if you don't need the rights check and just want to open a cross process mutex.

-a commented on Thu Jan 23 2020

This requests is not WPF-specific and probably belongs to corefx (now in the dotnet/runtime repo)

That said as far as I can tell MutexRights still exists and is public. The TryOpenExisting method seems to have moved and the functionality now be covered by MutexAcl.Create or Mutex.OpenExisting if you don't need the rights check and just want to open a cross process mutex.

I posted this feature request here because it was related to migrating WPF app to .NET Core.

As for MutexRights, it's not there and we need to specify MutexRights.Synchronize.

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

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

14条回答 默认 最新

  • weixin_40005887 weixin_40005887 2021-01-11 10:53

    One of those did?

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

    Nope, it's not -- that added new CreateXXX methods as an alternative to the missing constructors on Mutex, Semaphore, EventWaitHandle, FileInfo, DirectoryInfo, FileSecurity, DirectorySecurity.

    In this case we're missing OpenExisting and TryOpenExisting on Mutex, Semaphore and WaitHandle. I would have expected to see these implemented as extension methods in System.Threading.ThreadingAclExtensions, but they're not.

    Seems to be just an oversight that can be remedied. All the necessary XXXRights types already exist. do you see any issue?

    
    MembersMustExist : Member 'System.Threading.Mutex.OpenExisting(System.String, System.Security.AccessControl.MutexRights)' does not exist in the implementation but it does exist in the contract.
    MembersMustExist : Member 'System.Threading.Mutex.TryOpenExisting(System.String, System.Security.AccessControl.MutexRights, System.Threading.Mutex)' does not exist in the implementation but it does exist in the contract.
    MembersMustExist : Member 'System.Threading.Semaphore.OpenExisting(System.String, System.Security.AccessControl.SemaphoreRights)' does not exist in the implementation but it does exist in the contract.
    MembersMustExist : Member 'System.Threading.Semaphore.TryOpenExisting(System.String, System.Security.AccessControl.SemaphoreRights, System.Threading.Semaphore)' does not exist in the implementation but it does exist in the contract.
    MembersMustExist : Member 'System.Threading.EventWaitHandle.OpenExisting(System.String, System.Security.AccessControl.EventWaitHandleRights)' does not exist in the implementation but it does exist in the contract.
    MembersMustExist : Member 'System.Threading.EventWaitHandle.TryOpenExisting(System.String, System.Security.AccessControl.EventWaitHandleRights, System.Threading.EventWaitHandle)' does not exist in the implementation but it does exist in the contract.
    
    点赞 评论 复制链接分享
  • weixin_40005887 weixin_40005887 2021-01-11 10:53

    -a MutexRights does exist, as says. Not sure why you're not seeing it. But the method you want that accepts it does not exist.

    Even if we add this, it won't help your immediate project. Instead I suggest you create an extension method your project can use. Essentially the below code (untested):

    c#
    public class MyMutexExtension
    {
        [DllImport("kernel32", EntryPoint = "OpenMutexW", SetLastError = true, CharSet = CharSet.Unicode)]
        private static extern SafeWaitHandle OpenMutex(uint desiredAccess, bool inheritHandle, string name);
    
        public static Mutex TryOpenExisting(string name, MutexRights rights, out Mutex result)
        {
            SafeWaitHandle myHandle = Interop.Kernel32.OpenMutex((uint)rights, false, name);
    
            if (myHandle.IsInvalid)
            {
               return false;
            }
    
            result = new Mutex(initiallyOwned: false);
            SafeWaitHandle old = result.SafeWaitHandle;
            result.SafeWaitHandle = handle;
            old.Dispose();
    
            return true;
        }
    }
    
    点赞 评论 复制链接分享
  • weixin_39768083 weixin_39768083 2021-01-11 10:53

    They were not included in the original API Proposal.

    was it just oversight or was there a particular reason to avoid including them?

    If Jeremy has no issue, I'd be happy to help prepare a new API Proposal for these methods.

    Should we also consider backporting them?

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

    yup, didn't mean to suggest it was your oversight 😺

    Someone should probably add them but they seem easy to work around. Perhaps the community can contribute. do we need API review to add the exact same APi that exists in .NET Framework albeit as an extension method? I assume not...

    点赞 评论 复制链接分享
  • weixin_39926016 weixin_39926016 2021-01-11 10:53

    was it just oversight or was there a particular reason to avoid including them?

    Oversight on my part.

    点赞 评论 复制链接分享
  • weixin_39754603 weixin_39754603 2021-01-11 10:53

    do we need API review to add the exact same APi that exists in .NET Framework albeit as an extension method?

    Yes. Especially if it's an extension method (we want to see what type/assembly/package it's going into). If it was just a resurrection then it'd be a very fast nod, but we still do it so we're consistent that editing a ref.cs involved an API review.

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

    Ok maybe a low pri task for you (-a I suggest to work around as above)

    点赞 评论 复制链接分享
  • weixin_39938875 weixin_39938875 2021-01-11 10:53

    As we try migrating to .Net Core 3.1 primarily to focus on Mac, it was an unexpected bump in the road to discover this problem, which also impacts named EventWaitHandle.OpenExisting(). Will this be patched for .Net Core 3.1? Will it definitely be in .Net Core 5.0? Thank you.

    点赞 评论 复制链接分享
  • weixin_39717110 weixin_39717110 2021-01-11 10:53

    This issue is still open and the API hasn't even been reviewed. Since 5.0 already branched off of the master branch, I'd say the chances of this getting in are fairly low. And the chances for 3.1 are near zero, since already released versions don't get new APIs, only bugfixes.

    点赞 评论 复制链接分享
  • weixin_39768083 weixin_39768083 2021-01-11 10:53

    did you try the suggested workaround gave you here?

    Edit: I see you also want it on Mac. There might be a similar workaround too.

    I'll work on the API proposal.

    点赞 评论 复制链接分享
  • weixin_39938875 weixin_39938875 2021-01-11 10:53

    I did not try the workaround, because we primarily need this for the Mac Core3.1 target. Many thanks for continuing to look into it for us. Having said that, I'll be fiddling with more with alternatives, probably next week.

    点赞 评论 复制链接分享
  • weixin_39754603 weixin_39754603 2021-01-11 10:53

    we primarily need this for the Mac Core3.1 target

    Even if we create the method, I think it's just going to throw PlatformNotSupportedException on macOS... in general anything with rights/permissions/ACLs is Windows-only.

    What are you wanting to do with it on macOS?

    点赞 评论 复制链接分享
  • weixin_39768083 weixin_39768083 2021-01-11 10:53

    -a the APIs have been merged: https://github.com/dotnet/runtime/pull/43134 Note that these APIs are Windows-specific. If you need something for MacOS, let's discuss it in a new issue.

    点赞 评论 复制链接分享

相关推荐