C# – Calling a Web Method from ASPX Code Behind

asp.netcwebmethod

I'm trying to figure out a way that I can call a Web Method (located as a public static method in the code behind of an aspx page) from another ASPX Code Behind page.

This is the code behind of Page A.aspx

public partial class PageA : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
    // other code not relevant is here  
    }

    [WebMethod(true)]
    public static string GetStringInfo()
    {
         // do some stuff here to build my string
         // return string
    }
}

On page B, I need to be able to call GetStringInfo() during page load or some other event to get the information. the GetStringInfo() is fairly complex and for reasons outside of my control, can't be moved elsewhere or rebuilt presently.

How can I consume the web method above from another page's code behind?

I've tried instantiating a copy of the other page (PageB), such as:

public partial class PageB : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
       PageA page = new PageA();
       page.GetStringInfo();        
    }
}

The problem here is since it's dynamically compiled, I don't have an easy namespace to reference and access. I've tried adding one, and it ignores it.

This project is on .net 3.5, C#, and is a web site project (not a web application).

Any help is appreciated!

Best Answer

If the GetStringInfo method is static you don't need an instance of PageA to invoke it:

public partial class PageB : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
       string info = PageA.GetStringInfo();        
    }
}

Related Solutions

C# – How to call asynchronous method from synchronous method in C#

Asynchronous programming does "grow" through the code base. It has been compared to a zombie virus. The best solution is to allow it to grow, but sometimes that's not possible.

I have written a few types in my Nito.AsyncEx library for dealing with a partially-asynchronous code base. There's no solution that works in every situation, though.

Solution A

If you have a simple asynchronous method that doesn't need to synchronize back to its context, then you can use Task.WaitAndUnwrapException:

var task = MyAsyncMethod();
var result = task.WaitAndUnwrapException();

You do not want to use Task.Wait or Task.Result because they wrap exceptions in AggregateException.

This solution is only appropriate if MyAsyncMethod does not synchronize back to its context. In other words, every await in MyAsyncMethod should end with ConfigureAwait(false). This means it can't update any UI elements or access the ASP.NET request context.

Solution B

If MyAsyncMethod does need to synchronize back to its context, then you may be able to use AsyncContext.RunTask to provide a nested context:

var result = AsyncContext.RunTask(MyAsyncMethod).Result;

*Update 4/14/2014: In more recent versions of the library the API is as follows:

var result = AsyncContext.Run(MyAsyncMethod);

(It's OK to use Task.Result in this example because RunTask will propagate Task exceptions).

The reason you may need AsyncContext.RunTask instead of Task.WaitAndUnwrapException is because of a rather subtle deadlock possibility that happens on WinForms/WPF/SL/ASP.NET:

A synchronous method calls an async method, obtaining a Task.
The synchronous method does a blocking wait on the Task.
The async method uses await without ConfigureAwait.
The Task cannot complete in this situation because it only completes when the async method is finished; the async method cannot complete because it is attempting to schedule its continuation to the SynchronizationContext, and WinForms/WPF/SL/ASP.NET will not allow the continuation to run because the synchronous method is already running in that context.

This is one reason why it's a good idea to use ConfigureAwait(false) within every async method as much as possible.

Solution C

AsyncContext.RunTask won't work in every scenario. For example, if the async method awaits something that requires a UI event to complete, then you'll deadlock even with the nested context. In that case, you could start the async method on the thread pool:

var task = Task.Run(async () => await MyAsyncMethod());
var result = task.WaitAndUnwrapException();

However, this solution requires a MyAsyncMethod that will work in the thread pool context. So it can't update UI elements or access the ASP.NET request context. And in that case, you may as well add ConfigureAwait(false) to its await statements, and use solution A.

Update, 2019-05-01: The current "least-worst practices" are in an MSDN article here.

Best Answer

Related Solutions

C# – How to call asynchronous method from synchronous method in C#

Related Topic