The Visual Studio .NET or Visual Studio 2005 debugger stops responding when it calls an XML Web Service in asynchronous mode (315624)
The information in this article applies to:
- Microsoft Visual Studio .NET (2002), Professional Edition
- Microsoft Visual Studio .NET (2002), Enterprise Architect Edition
- Microsoft Visual Studio .NET (2002), Enterprise Developer Edition
- Microsoft Visual Studio .NET (2002), Academic Edition
- Microsoft Visual Studio .NET (2003), Enterprise Architect Edition
- Microsoft Visual Studio .NET (2003), Enterprise Developer Edition
- Microsoft Visual Studio .NET (2003), Academic Edition
- Microsoft Visual Studio 2005 Standard Edition
- Microsoft Visual Studio 2005 Professional Edition
This article was previously published under Q315624 SYMPTOMS When you run a single-threaded apartment console Web client
application by using the Visual Studio .NET or Visual Studio 2005 debugger, the client application
cannot complete an asynchronous call to an XML Web service. However, if the Web
client is started without the debugger, the call works as expected.
CAUSE This behavior occurs because the client application makes
an asynchronous call to the XML Web service, and then waits for the XML Web
service to fire an event. While the client is waiting, the main thread of the
client application automatically enters a sleep mode.
If you are running the client application in
debug mode, the Csm.dll debugger component file is called to handle the
debugger event. However, because the main thread is in sleep mode, the event
callback cannot be completed and the client application stops responding.
RESOLUTION A console application that blocks the primary thread can
receive the asynchronous response from the Web service during a debugging
session. However, in this case, the application was launched in a
single-threaded apartment. Resolution 1 By default, .NET-connected console applications run in a
multithreaded apartment (MTA). Therefore, you can resolve this problem by
removing the STAThread attribute that appears before the Main function (see the sample code in step 10 of the "Steps to
Reproduce the Behavior" section). This permits the application to retrieve the
result from another thread in the MTA while the debugger is executing. Resolution 2 A Microsoft Windows-based application should run its primary
thread in a single-threaded apartment (the STAThread attribute). However, because a Windows application is
event-driven, the blocking loop does not have to prevent shutdown. Therefore,
you can also use an event-driven Windows client application to resolve this
problem. STATUSThis
behavior is by design.
Modification Type: | Major | Last Reviewed: | 3/3/2006 |
---|
Keywords: | kbvs2005applies kbvs2005swept kbvs2002sp1sweep kbBug kbDebug kbide kbprb KB315624 kbAudDeveloper |
---|
|