I\'m trying to call an async method (in an ASP.NET Web API 2 app) without awaiting for the result. I mean I want to main thread to continue executing and no-wait for called
You've got it right.
The first method is what you need.
// The caller methods:
public static void Log1(Exception exception, object parameters) {
LogAsync(exception, ip, method, parameters);
}
The problem may be somewhere else. How do you test this?
Log1's LogAsync
will be executed on a different thread. It's like fire and forget which is exactly what you need.
EDIT: Try changing the LogAsync method to:
// The async method:
private static void LogAsync(Exception exception, string ip, MethodBase method, object parameters) {
Task.Factory.StartNew(delegate {
// some stuff });
}
I'm trying to call an async method (in an ASP.NET Web API 2 app) without awaiting for the result.
Are you sure that's what you want to do? On ASP.NET, if you start up independent work like this (that is, work not related to an HTTP request), then that work may be aborted without your knowledge. In this scenario, your methods are called "log", so presumably they are logging asynchronously. So you only want to avoid the await
if it's perfectly acceptable to occasionally lose logs. If you want your logs to be reliable, you'll need to keep the await
. Your call.
Assuming that it's OK to occasionally lose logs, then you should at least register the work with the ASP.NET runtime. If you're on .NET 4.5.2, you can use HostingEnvironment.QueueBackgroundWorkItem
, as such:
public static void Log(Exception exception, object parameters) {
HostingEnvironment.QueueBackgroundWorkItem(_ =>
LogAsync(exception, ip, method, parameters));
}
If you're on an older version of .NET (4.5 or 4.5.1), you can use my AspNetBackgroundTasks library:
public static void Log(Exception exception, object parameters) {
BackgroundTaskManager.Run(() =>
LogAsync(exception, ip, method, parameters));
}
The semantics between the two are slightly different (I have a writeup on my blog), but they both register the work with the ASP.NET runtime so at least it's not entirely unreliable like Task.Factory.StartNew
or Task.Run
is.