{"id":22394,"date":"2019-03-28T14:29:50","date_gmt":"2019-03-28T21:29:50","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=22394"},"modified":"2021-03-23T17:15:48","modified_gmt":"2021-03-24T00:15:48","slug":"migrating-delegate-begininvoke-calls-for-net-core","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/migrating-delegate-begininvoke-calls-for-net-core\/","title":{"rendered":"Migrating Delegate.BeginInvoke Calls for .NET Core"},"content":{"rendered":"

I recently worked with a couple customers migrating applications to .NET Core that had to make code changes to workaround BeginInvoke<\/code> and EndInvoke<\/code> methods on delegates not being supported on .NET Core. In this post, we’ll look at why these APIs aren’t implemented for .NET Core, why their usage isn’t caught by the .NET API Portability Analyzer<\/a>, and how to fix code using them to work with .NET Core.<\/p>\n

About the APIs<\/h2>\n

As explained in .NET documentation<\/a>, the BeginInvoke<\/code> method on delegate types allows them to be invoked asynchronously. BeginInvoke<\/code> immediately (without waiting for the delegate to complete) returns an IAsyncResult<\/code> object that can be used later (by calling EndInvoke<\/code>) to wait for the call to finish and receive its return value.<\/p>\n

For example, this code calls the DoWork<\/code> method in the background:<\/p>\n

delegate int WorkDelegate(int arg);\r\n...\r\nWorkDelegate del = DoWork;\r\n\r\n\/\/ Calling del.BeginInvoke starts executing the delegate on a\r\n\/\/ separate ThreadPool thread\r\nConsole.WriteLine(\"Starting with BeginInvoke\");\r\nvar result = del.BeginInvoke(11, WorkCallback, null);\r\n\r\n\/\/ This writes output to the console while DoWork is running in the background\r\nConsole.WriteLine(\"Waiting on work...\");\r\n\r\n\/\/ del.EndInvoke waits for the delegate to finish executing and \r\n\/\/ gets its return value\r\nvar ret = del.EndInvoke(result);<\/pre>\n
The Asynchronous Programming Model (APM)<\/a> (using IAsyncResult<\/code> and BeginInvoke<\/code>) is no longer the preferred method of making asynchronous calls.<\/strong> The Task-based Asynchronous Pattern (TAP)<\/a> is the recommended async model as of .NET Framework 4.5. Because of this, and because the implementation of async delegates depends on remoting features not present in .NET Core, BeginInvoke<\/code> and EndInvoke<\/code> delegate calls are not supported in .NET Core. This is discussed in GitHub issue dotnet\/corefx #5940<\/a>.<\/p>\n
Of course, existing .NET Framework code can continue to use IAsyncResult<\/code> async patterns, but running that code on .NET Core will result in an exception similar to this at runtime:<\/p>\n
Unhandled Exception: System.PlatformNotSupportedException: Operation is not supported on this platform.\r\n   at BeginInvokeExploration.Program.WorkDelegate.BeginInvoke(Int32 arg, AsyncCallback callback, Object object)<\/pre>\n
Why doesn’t ApiPort catch this?<\/h2>\n
There are other APIs that are supported on .NET Framework that aren’t supported on .NET Core, of course. What made this one especially confusing for the customers I worked with was that the .NET API Portability Analyzer<\/a> didn’t mention the incompatibility in its report. Following our migration guidance<\/a>, the customers had run the API Port tool to spot any APIs used by their projects that weren’t available on .NET Core. BeginInvoke<\/code> and EndInvoke<\/code> weren’t reported.<\/p>\n
The reason for this is that BeginInvoke<\/code> and EndInvoke<\/code> methods on user-defined delegate types aren’t actually defined in .NET Framework libraries. Instead, these methods are emitted by the compiler (see the ‘Important’ note in Asynchronous Programming Using Delegates<\/a>) as part of building code that declares a delegate type.<\/p>\n
In the code above, the WorkDelegate<\/code> delegate type is declared in the C# code. The IL of the compiled library includes BeginInvoke<\/code> and EndInvoke<\/code> methods, added by the compiler:<\/p>\n
.class auto ansi sealed nested private WorkDelegate\r\n        extends [mscorlib]System.MulticastDelegate\r\n{\r\n.method public hidebysig specialname rtspecialname \r\n        instance void  .ctor(object 'object',\r\n                                native int 'method') runtime managed\r\n{\r\n} \/\/ end of method WorkDelegate::.ctor\r\n\r\n.method public hidebysig newslot virtual \r\n        instance int32  Invoke(int32 arg) runtime managed\r\n{\r\n} \/\/ end of method WorkDelegate::Invoke\r\n\r\n.method public hidebysig newslot virtual \r\n        instance class [mscorlib]System.IAsyncResult \r\n        BeginInvoke(int32 arg,\r\n                    class [mscorlib]System.AsyncCallback callback,\r\n                    object 'object') runtime managed\r\n{\r\n} \/\/ end of method WorkDelegate::BeginInvoke\r\n\r\n.method public hidebysig newslot virtual \r\n        instance int32  EndInvoke(class [mscorlib]System.IAsyncResult result) runtime managed\r\n{\r\n} \/\/ end of method WorkDelegate::EndInvoke\r\n\r\n} \/\/ end of class WorkDelegate<\/pre>\n
 <\/p>\n
The methods have no implementation because the CLR provides them at runtime.<\/p>\n
The .NET Portability Analyzer only analyzes calls made to methods declared in .NET Framework assemblies, so it misses these methods, even though they may feel like .NET dependencies. Because the Portability Analyzer decides which APIs to analyze by looking at the name and public key token of the assembly declaring the API, the only way to analyze BeginInvoke<\/code> and EndInvoke<\/code> methods on user-defined delegates would be to analyze all<\/em> API calls, which would require a large change to the portability analyzer and would have undesirable performance drawbacks.<\/p>\n
How to remove BeginInvoke\/EndInvoke usage<\/h2>\n
The good news here is that calls to BeginInvoke<\/code> and EndInvoke<\/code> are usually easy to update so that they work with .NET Core. When fixing this type of error, there are a couple approaches.<\/p>\n
First, if the API being invoked with the BeginInvoke<\/code> call has a Task<\/code>-based asynchronous alternative, call that instead. All delegates expose BeginInvoke<\/code> and EndInvoke<\/code> APIs, so there’s no guarantee that the work is actually done asynchronously (BeginInvoke<\/code> may just invoke a synchronous workflow on a different thread). If the API being called has an async alternative, using that API will probably be the easiest and most performant fix.<\/p>\n
If there are no Task-based alternatives available, but offloading the call to a thread pool thread is still useful, this can be done by using Task.Run<\/code> to schedule a task for running the method. If an AsyncCallback<\/code> parameter was supplied when calling BeginInvoke<\/code>, that can be replaced with a call to Task.ContinueWith<\/code>.<\/p>\n
Task-based Asynchronous Pattern (TAP) documentation has guidance on how to wrap IAsyncResult<\/code>-style patterns as Task<\/code>s<\/a> using TaskFactory<\/code>. Unfortunately, that solution doesn’t work for .NET Core because the APM APIs (BeginInvoke<\/code>, EndInvoke<\/code>) are still used inside the wrapper. The TAP documentation guidance is useful for using older APM-style code in .NET Framework TAP scenarios, but for .NET Core migration, APM APIs like BeginInvoke<\/code> and EndInvoke<\/code> need to be replaced with synchronous calls (like Invoke<\/code>) which can be run on a separate thread using Task.Run<\/code>.<\/p>\n
As an example, the code from earlier in this post can be replaced with the following:<\/p>\n
delegate int WorkDelegate(int arg);\r\n...\r\nWorkDelegate del = DoWork;\r\n\r\n\/\/ Schedule the work using a Task and \r\n\/\/ del.Invoke instead of del.BeginInvoke.\r\nConsole.WriteLine(\"Starting with Task.Run\");\r\nvar workTask = Task.Run(() => del.Invoke(11));\r\n\r\n\/\/ Optionally, we can specify a continuation delegate \r\n\/\/ to execute when DoWork has finished.\r\nvar followUpTask = workTask.ContinueWith(TaskCallback);\r\n\r\n\/\/ This writes output to the console while DoWork is running in the background.\r\nConsole.WriteLine(\"Waiting on work...\");\r\n\r\n\/\/ We await the task instead of calling EndInvoke.\r\n\/\/ Either workTask or followUpTask can be awaited depending on which\r\n\/\/ needs to be finished before proceeding. Both should eventually\r\n\/\/ be awaited so that exceptions that may have been thrown can be handled.\r\nvar ret = await workTask;\r\nawait followUpTask;<\/pre>\n
This code snippet provides the same functionality and works on .NET Core.<\/p>\n
Resources<\/h2>\n