1

I'm converting a C# .NET Framework project over to .NET Core. It compiles without errors or warnings and runs fine on Windows, but when I try it on CentOS 7, I get a System.PlatformNotSupportedException when I try to create an instance of EventWaitHandle. Here is the code:

this.eventHandle = new EventWaitHandle(initialState, resetMode, name);

There is clearly .NET Core 2.1 support for this class as there is MS documentation for it here:

https://learn.microsoft.com/en-us/dotnet/api/system.threading.eventwaithandle.-ctor?view=netcore-2.1

Is this as simple as the error describes and this class is not supported across multiple platforms? If so, why is it included in .NET Core? Could there be anything else at play here?

If it is simply not supported, is there an alternative class that someone can suggest that is supported completely in .NET Core 2.1?

Thanks.

mojoker
  • 308
  • 2
  • 14
  • Are you using any NuGet packages? – Moffen Nov 28 '18 at 19:39
  • Adding some more info... I am using this for cross-process synchronization. – mojoker Nov 28 '18 at 21:23
  • @Moffen, I'm not currently using any NuGet packages. – mojoker Nov 28 '18 at 21:24
  • The obvious approach would probably be to cook up a pull request so [events are implemented in a POSIX or at least Linux way](https://stackoverflow.com/a/33099359/4137916), then .NET Core 2.2 will have support... obviously, not completely trivial. Depending on your scenario (i.e. not too many events, not too many calls), you could implement some poor man's synchronization mechanism by polling files. – Jeroen Mostert Nov 29 '18 at 15:39
  • Hey @mojoker did you ever find a solution for this? It looks as though it still hasn't been fixed. – petedotg Jun 01 '20 at 05:59

1 Answers1

3

.Net Core has some platform specific apis. This is one of them. It is the named handles it can't handle, see the source

    public EventWaitHandle(bool initialState, EventResetMode mode, string name)
    {
        if(name != null)
        {
#if PLATFORM_UNIX
            throw new PlatformNotSupportedException(Environment.GetResourceString("PlatformNotSupported_NamedSynchronizationPrimitives"));
#else
            if (System.IO.Path.MaxPath < name.Length)
            {
                throw new ArgumentException(Environment.GetResourceString("Argument_WaitHandleNameTooLong", name));
            }
#endif
        }

        ...

Some more interesting reads here:

I'm uncertain what .NET technology you should be using instead. If you don't require cross-process synchronization, you don't need to specify a name for EventWaitHandle, or you can use a different subclass of EventWaitHandle, such as ManualResetEvent or AutoResetEvent.

Peter Bons
  • 26,826
  • 4
  • 50
  • 74