Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MulticastDelegate, BeginInvoke throws NotSupportedException #16312

Closed
christiannagel opened this issue Feb 6, 2016 · 11 comments
Closed

MulticastDelegate, BeginInvoke throws NotSupportedException #16312

christiannagel opened this issue Feb 6, 2016 · 11 comments
Labels
area-System.Runtime
Milestone
1.0.0-rtm

Comments

@christiannagel
Copy link

Invoking the BeginInvoke method of a MulticastDelegate derived delegate compiles fine with .NET Core, but throws a NotSupportedException.
Should this really be the case?
Sample code is here, .NET 4.6 runs ok, but .NET Core fails with the mentioned exception:
https://github.com/ProfessionalCSharp/ProfessionalCSharp6/tree/master/Synchronization/SynchronizationSamples/AsyncDelegate

Thanks,
Christian
@joshfree joshfree assigned ghost Feb 9, 2016
@jkotas
Copy link
Member

jkotas commented Feb 9, 2016

Async delegates are not in .NET Core for several reasons:

  • Async delegates use deprecated IAsyncResult-based async pattern. This pattern is generally not supported throughout .NET Core base libraries, e.g. System.IO.Stream does not have IAsyncResult-based overloads for Read/Write methods in .NET Core.
  • Async delegates depend on remoting (System.Runtime.Remoting) under the hood. Remoting is not in .NET Core - implementation of async delegates without remoting would be challenging.

@jkotas jkotas closed this as completed Feb 9, 2016
@christiannagel
Copy link
Author

Can't this be solved by compilation errors instead of runtime exceptions?

@jkotas
Copy link
Member

jkotas commented Feb 10, 2016

@jaredpar What do you think?

@jaredpar
Copy link
Member

Generally the compiler enables / disables features by looking at the types for hints. Is there anything we can key on here to know to exclude these members?

@christiannagel
Copy link
Author

just refreshing this thread to see if something can be done for compilation errors instead of runtime exceptions

@jnm2
Copy link
Contributor

jnm2 commented Mar 7, 2016

+1 For compiler safety. How does it make sense to make an API available that is guaranteed to be the wrong thing to use? The ideal experience is for BeginInvoke not to exist on core.

Kemyke referenced this issue in Kemyke/abot Oct 2, 2016
@Kemyke
Remove async delegates which are not supported in .net core (https://…
6c06489 
…github.com/dotnet/corefx/issues/5940)
tpluscode referenced this issue in dotnetrdf/dotnetrdf Apr 9, 2017
@tpluscode
move parallel tests to full .NET
ee5ea01 
apparently we're using multicast delegates which are not supported on .NET Standard. see dotnet/corefx#5940
mjrousos referenced this issue in mjrousos/NETworkManager Nov 28, 2018
@mjrousos
#if out Delegate.BeginInvoke/EndInvoke usage
6f41f99 
https://github.com/dotnet/corefx/issues/5940
@weltkante
Copy link
Contributor

Linking back to the official blog post, in case someone comes across the github issue before finding the post. It has some more details and suggestions how to replace Delegate.BeginInvoke invocations.

https://devblogs.microsoft.com/dotnet/migrating-delegate-begininvoke-calls-for-net-core/

RussKie referenced this issue in RussKie/winforms Aug 30, 2019
@RussKie
fix: PictureBox.LoadAsync throws PlatformNotSupportedException
e8bb804 
Async delegates have been deprecated in .NET Core (see https://github.com/dotnet/corefx/issues/5940)
for reasons such as:
* Async delegates use deprecated IAsyncResult-based async pattern.
This pattern is generally not supported throughout .NET Core base libraries.
* Async delegates depend on remoting (System.Runtime.Remoting) under the
hood. Remoting is not supported in .NET Core.

For more detailed reasons and migration strategies please refer to
https://devblogs.microsoft.com/dotnet/migrating-delegate-begininvoke-calls-for-net-core/

In case of WinForms, async pattern predates the Task-based Asynchronous
Pattern and it does not return awaitables.
In order to minimise the change to the public API surface we continue
to expose the existing API and just re-route the image loading routine
to a `Task` runner under the covers.

Fixes dotnet#242
Fixes dotnet#1548
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 1.0.0-rtm milestone Jan 31, 2020
0xC0000054 added a commit to 0xC0000054/gmic-sharp that referenced this issue May 9, 2020
@0xC0000054
Replace Delegate.BeginInvoke with Task.Run
df46a44 
Delegate.BeginInvoke was removed in .NET Core.
See dotnet/runtime#16312.
@rolfbjarne rolfbjarne mentioned this issue Jul 9, 2020
Closed
61 tasks
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jul 13, 2020
@rolfbjarne
[monotouch-test] Use a normal thread instead of MulticastDelegate.Beg…
fea3722 
…inInvoke in AVAssetImageGeneratorTest.

MulticastDelegate.BeginInvoke isn't supported in .NET.

Ref: dotnet/runtime#16312
@rolfbjarne rolfbjarne mentioned this issue Jul 13, 2020
Merged
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jul 13, 2020
@rolfbjarne
[monotouch-test] Use a normal thread instead of MulticastDelegate.Beg…
46f25ba 
…inInvoke.

MulticastDelegate.BeginInvoke isn't supported in .NET.

Ref: dotnet/runtime#16312
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jul 13, 2020
@rolfbjarne
[monotouch-test] Use a normal thread instead of MulticastDelegate.Beg…
baeed94 
…inInvoke.

MulticastDelegate.BeginInvoke isn't supported in .NET.

Ref: dotnet/runtime#16312
rolfbjarne added a commit to xamarin/xamarin-macios that referenced this issue Jul 13, 2020
@rolfbjarne
[monotouch-test] Use a normal thread instead of MulticastDelegate.Beg…
96327de 
…inInvoke in AVAssetImageGeneratorTest. (#9067)

MulticastDelegate.BeginInvoke isn't supported in .NET.

Ref: dotnet/runtime#16312
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Aug 25, 2020
@rolfbjarne
[tests] Ignore a don't link test that calls MulticastDelegate.BeginIn…
87efe86 
…voke.

MulticastDelegate.BeginInvoke isn't supported in .NET.

Ref: dotnet/runtime#16312

Fixes this test failure:

    DontLink.DontLinkRegressionTests
    [FAIL] Bug5354 : System.PlatformNotSupportedException : Operation is not supported on this platform.
        at DontLink.DontLinkRegressionTests.Bug5354() in [...]/xamarin-macios/tests/linker/ios/dont link/DontLinkRegressionTests.cs:line 64
        at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Aug 26, 2020
@rolfbjarne
[tests] Ignore a link sdk test that calls MulticastDelegate.BeginInvoke.
a44fdae 
MulticastDelegate.BeginInvoke isn't supported in .NET.

Ref: dotnet/runtime#16312
@ghost ghost locked as resolved and limited conversation to collaborators Jan 3, 2021
@danmoseley
Copy link
Member

Generally the compiler enables / disables features by looking at the types for hints. Is there anything we can key on here to know to exclude these members?

this is now an old issue, but an internal customer pointed me at it today and I see there have grown to be a lot of thumbs up above, over time. @jkotas did you see @jaredpar question above -- do you think it might be feasible?

@danmoseley danmoseley reopened this Apr 10, 2023
@danmoseley danmoseley reopened this Apr 11, 2023
@jkotas
Copy link
Member

jkotas commented Apr 11, 2023 •
edited
Loading

This should be an analyzer. It is proposed by dotnet/roslyn-analyzers#2807. dotnet/roslyn-analyzers#2972 was an attempt to implement this analyzer, but it was closed due to unaddressed feedback.

Changing Roslyn to stop emitting BeginInvoke/EndInvoke would be a breaking change. This was discussed in dotnet/roslyn#50826. I think we can consider it after the analyzer is in place for several years and we have reasonable confidence that it won't affect too much code.

Resolving as duplicate of dotnet/roslyn-analyzers#2807

@jkotas jkotas closed this as completed Apr 11, 2023
@danmoseley
Copy link
Member

Got it, thanks for the links. Perhaps someone here might be interested in working on that analyzer.

@danmoseley
Copy link
Member

danmoseley commented Apr 11, 2023 •
edited
Loading

cc @wikimonkey in case he's interested in the links/info above.

also linking dotnet/docs#34937

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area-System.Runtime
Projects
None yet
Milestone
1.0.0-rtm
Development

No branches or pull requests
7 participants
@jaredpar @christiannagel @weltkante @danmoseley @jkotas @jnm2 @msftgits