We Keep Coding

Is there an easy way to simulate events between WCF service and WCF client?

So I've achieved localhost WCF Named Pipes communication between client EXE and server EXE. I can call class methods on the server over localhost. So, it's like an IPC/RPC. However, if the server's class method takes a long time to execute, then it's best for me to throw that into a thread so that the server class method finishes and runs this thread in the background. Okay, fine, but then when the thread is finished its long task, I want to alert the client without having to use a timer on the client that would check that class method. A timer hitting a class method is a lot more inefficient than a raised event. It's like I need to raise an event on the client from the server. Is there an easy way to do this or to at least simulate it, without a lot of confusing work?

This is an answer formulated from my comment to the OP's question
You could make your WCF methods asynchonous then it's a simple matter of async/await or do away with WCF completely and use built-in async with NamedPipeClientStream (which is still await compatible). Not to mention a speed boost in the latter when doing away with verbose XML SOAP encoding
OP:
#MickyD You were right on the async/await thing now that I have studied that and implemented a test that works. That allows me to almost simulate a callback on a long running task and with minimal lines of code
e.g. to build upon the OP's answer but to use async/await correctly:
Client code
private async void button1_Click(object sender, EventArgs e) // <-- note async
{
label1.Text = await client.GetDataAsync(textBox1.Text); // <-- note await. New method
}
Now you could be tempted to use Task.Run but doing so is bad because:
Task.Run is best suited for compute-bound operations which we aren't.
Task.Run will at the most use an expensive thread-pool thread
We're performing an I/O operation and as such can benefit from I/O Completion Ports and "there is no thread" philosphy of IOCP present in Task I/O bound operations. As such when we make the server call via GetDataAsync, we don't waste a thread waiting for a result.
WCF Server
Here we simulate a lengthy operation by waiting, but instead of using Sleep which isn't Task-aware, we use Task.Delay which is an awaitable operation.
Task<string> async GetDataAsync (string text)
{
await Task.Delay (Timespan.FromSeconds(5));
return text + " processed";
}

So, let's say you have a button click in your UI that does a WCF synchronous method call on the WCF service, and that synchronous method takes a long time to run. Obviously, you don't want to block the UI from updating while that long running task executes. Naturally, you might be thinking about a callback. As in, you make the call to the server, and the class method on the server spawns a thread and runs that task, and when it's done, it returns back to the client a result via a callback.
To set that all up on WCF involves many complex, confusing, poorly documented steps, actually. But there's a much easier way, and it doesn't involve WCF code at all, and doesn't involve you changing anything on the WCF service, nor editing any WCF configurations. The trick is introduced in .NET 4.5 and greater. It's called async and await. Here is an example of a button click that calls a WCF service method that takes a long time to run and then returns the result when it's finished, and yet the GUI doesn't lock up and can handle other events.
1. First, to simulate a slow task, edit your WCF service project's shared class method and add this line in before the return result so that you can simulate a 5 second pause:
Thread.Sleep(5000); // requires using System.Threading;
In my case, I put that in my GetData() method.
2. Now switch to your WCF client project. You may have a button click handler that looks like this, as an example:
private void button1_Click(object sender, EventArgs e)
{
string returnString = client.GetData(textBox1.Text));
label1.Text = returnString;
}
So, switch that with three minor changes:
a. Add using System.Threading.Tasks;.
b. Change private void... to private async void... on your button click handler.
c. Utilize await Task.Run(...) with your slow method call.
Thus, the code would look like so:
private async void button1_Click(object sender, EventArgs e)
{
// Task.Run() requires "using System.Threading.Tasks;"
string returnString = await Task.Run(() => client.GetData(textBox1.Text));
label1.Text = returnString;
}
The end result is that when you click the button in the WCF client project, the GetData() class method is called on the WCF service project in a background thread, and, when finished, it comes back to that await statement and returns the result to the variable assignment. In my case, I clicked the button and nothing happened for 5 seconds -- the label with the result string didn't change. However, the GUI wasn't locked up -- I could drag the window around, type in other fields, click other form buttons, and so on. So, it's almost like a callback event handler, but not exactly. Still, it serves the same functionality and can be used in place of a callback event handler in most cases. And it involves far less code.

C# Web App thread

i'm in trouble. In my web app i have a code that creates a thread on the Click event of a button to perform a data intensive task, the is like this:
protected void button_Click(object sender, EventArgs e)
{
// Show loader image
loader.Show();
// Creating the thread
System.Threading.ParameterizedThreadStart ts = new System.Threading.ParameterizedThreadStart(RunThread);
Thread t = new Thread(ts);
t.Name = "BackgroundThread";
t.Priority = ThreadPriority.AboveNormal;
t.Start(HttpContext.Current);
}
private void RunThread(object state)
{
// Setting the current thread property as the background thread
CurrentThread = Thread.CurrentThread;
if (IsThreadRunning(CurrentThread))
{
CurrentThread.Join(TimeSpan.FromMinutes(6d));
}
// DO SOME HEAVY STUFF
}
In the button click i show the loader. The problem is: Even calling Join in the BackgroundThread, the Page_Load event gets called frequently making the page refresh. In other words, while the RunThread doesn´t finish, the Page_Load is getting called. Could i prevent this from happening?
OBS: What i wanna do is: show the loader while the data intensive thread is running without make repetitive refreshs on the page.

The only way to check long running task status from web page without polling (making postback from time to time) is to use Web Sockets, but i'm pretty sure using it would be big overhead for this kind of tasks.
I would use ajax requests to prevent full page reload.
Seems like you need to read more about the whole web request and response process.

Silverlight and problems with async call

I have some code that works as follows:
App.xaml calls a SetUp() method which populates a local collection using async calls and exposes the collection as a public property.
That's all good.
Now I make an instance of the first page in my Silverlight app like so
private void Application_Startup(object sender, StartupEventArgs e)
{
this.RootVisual = new Summary();
}
In the constructor of Summary() I expect those async calls to have been complete and my collection to be filled but the async calls have not yet complete. Even if I do a Thread.Sleep(100000....) before i make an instance on Summary() this is the case
And the thing is that until the constructor of Summary() is exited and the UI displayed to the user my async calls do not get kicked off!
What!!!
Is there anything I can do about that or is that just the way asyn calls work i.e. they wait until the current until of work finished before firing?

This is how I work round this situation (I'll use simple string download as an example):-
private void Application_Startup(object sender, StartupEventArgs e)
{
WebClient web = new WebClient();
web.DownloadStringCompleted += (s, args) =>
{
// Do stuff with args.Result);
this.RootVisual = new Summary();
};
web.DownloadStringAsync(new Uri("SomeUrl.txt", UriKind.Relative));
}
Note that the construction of Summary and the assignment to RootVisual are defered until the asynchronous download is complete.

Silverlight was specifically designed to not have any blocking operations -- that's why you have to do async in the first place. What you really have to do is make your app run properly while waiting for the async completion handler to execute.

This is by design. The alternative would be that the user has to wait longer before he sees anything at all.
If you really want to prevent showing an incomplete summery then first shown another page with 'waiting' or a progress bar. Fire the async events from that page or its parent. Then show the Summary when the async call returns.
To deal with an incomplete Summary you might want to use ICommand

I know this is an old thread, but for all following reader i want to provide my experience with a similar problem. If i understood you correctly - the reason why your async calls do not complete is because you block the main thread. I ran into the same problem, if you block the main thread none of the other threads continue. The solution was to do the async calls inside a backgroundworker and show, like pauldendulk said, a waiting - page. Use Debug.WriteLine() to monitor the process in the output.

How to use Asynchronous Programming Model in ASP.NET?

I have an ASP.NET page that requires data from another DLL and the process might take a long time. So, I set out to use APM. But when I try that, the page just never stops loading. It loads indefinitely. Is there something I'm doing wrong?
Here is my web page:
List<string> allVoices;
GetAllVoicesDelegate getVoicesDelegate;
internal delegate List<String> GetAllVoicesDelegate();
protected void Page_Load(object sender, EventArgs e)
{
Page.AddOnPreRenderCompleteAsync(new BeginEventHandler(BeginGetDropDownValues),
new EndEventHandler(EndGetDropDownValues));
}
public IASyncResult BeginGetDropDownValues(object o,EventArgs args,AsyncCallback cb,object obj)
{
getVoicesDelegate = MyLib.getStrings;
return getVoicesDelegate.BeginInvoke(EndGetDropDownValues,null);
}
public void EndGetDropDownValues(IASyncResult ar)
{
allVoices = getVoicesDelegate.EndInvoke(ar);
}
protected override OnPreRenderComplete(EventArgs e)
{
if(allVoices.Count>0)
{
foreach(String str in allVoices)
{
Response.Write(str);
}
}
base.OnPreRenderComplete(e);
}
Here is the MyLib.getStrings() method in another DLL:
public List<String> getStrings()
{
List<String> allStr=new List<string>();
allStr.Add("1");
allStr.Add("2");
allStr.Add("3");
allStr.Add("4");
}

If you have to get data from a long running process, making async calls from the web page won't help you because in the end, the process needs to finish before the page can finish rendering. Making async calls frees you to do other stuff in the mean time, but the page can't render until all the activity on it is finished.
I think you'll have to take a different approach, either using Ajax to poll the server until the response is ready, or creating an intermediate page that tells the user to wait until the process is complete. Once it's complete, the page refreshes and the user sees the data.

I'm not overly familiar with your approach to asynchronous computing in asp.net (I generally use ajax to make requests to web services, etc.)
One possible flaw, from my point of view is the OnPreRenderComplete handler. This handler is not asynchronous to the best of my knowledge. It is used to handle the event of when all page controls are loading and ready.
The OnPreRenderComplete method is called when the prerendering stage of the page life cycle is complete. At this stage of the page life cycle, all controls are created and the page is ready to render the output.
In this event handler, you are making reference to allVoices class-level member which is processed by the async handlers. Is it possible then the code in this handler has to wait for the async delegate to complete? (in essence defeating the purpose of async).
Again just a guess. What happens if you take out the `OnPreRenderComplete' handler? or comment out the code within?
Additionally - I think the article you referenced is a little outdated and may not apply to web application development? Generally asynchronous programming on the web is done via AJAX and/or Web services/WCF?

Most likely your problem is your ASP.NET page compiling (typically takes seconds), and not the dll loading (typically takes only a few milliseconds).

The code sample you have provided launches some work on a separate thread and allows the asp.net worker process to continue processing your page request without blocking on your long running task. If the long running task takes a long time to complete, then your page will take a long time to render.
Start by replacing the begin with some kind of mocked up code to return an invoice. If your page completes almost immediately, then your async wiring is correct and you probably need to move to some kind of polling approach which uses the first request to start the task and renders a "we are processing your request" page to the user. This page then uses ajax to poll the system for some kind of completion flag, once that is received, the user is redirected to the result page and the results are displayed.

Not responding window

My code calls a Web service method which takes a few minutes to perform the operation.
During that time my window becomes non responsive and it shows a complete white screen.
I don't want to the call method from a different thread.
It it the best way to handle it?
Environment: C#, web service

The BackgroundWorker is your friend.
Here's an example of how I use a BackgroundWorker with a WebService. Basically, there's no way to do intensive operations on the UI side without using a separate thread. The BackgroundWorker is the nicest way of running on a separate thread.

To have a responsive UI, you must use another thread.
But if you use visual studio, the generated client class have asynchronous method signatures wich would do it for you. If your method is
"GetData", then you should have a method called "GetDataAsync" wich would not freeze your window.
Here is an example :
WsClient client;
protected override void Load() {
base.Onload();
client = new WsClient();
client.GetDataCompleted += new GetDataCompletedEventHandler(client_GetDataCompleted);
}
//here is the call
protected void Invoke()
{
client.GetDataAsync(txtSearch.Text);
}
//here is the result
void client_GetDataCompleted(object sender, GetDataCompletedEventArgs e)
{
//display the result
txtResult.Text = e.Result;
}

You can make the request on a separate thread, which will leave the UI thread responsive. You'll need to synchronise the response back to the UI thread once you've finished.