P
Paul Turelinckx
We are building a large client-server application based on XML WebServices. A lot of shared code is encapsulated in class libraries used by both the client app and the web services (all written in C#). Recently we randomly have the "Server did not recognize the value of HTTP Header SOAPAction: <namespace><webmethod>" exception
Initially we thought this to be caused by a wrong (outdated) assembly in one of the web service bin directories. However, the problem sometimes remains after a complete rebuild of all web services ('copy local = true' for all references). But we noticed that restarting IIS or editing the web.config in the application root fixed it temporarily (because of a recompile?). Accessing the asmx file for a faulty web service by IE shows the web service, but without the web methods. A look into the assemblies (using ILDASM) or checking trace information (trace.axd) showed everything to be normal
So what we are looking for now is: how can we trace/debug this kind of trouble to find what's causing it
I saw Matt Greer's question about a similar problem (2/3/2004), but I guess he is having the exception consistenly, while in our case it appears to be random
Any input would be welcome
Paul.
Initially we thought this to be caused by a wrong (outdated) assembly in one of the web service bin directories. However, the problem sometimes remains after a complete rebuild of all web services ('copy local = true' for all references). But we noticed that restarting IIS or editing the web.config in the application root fixed it temporarily (because of a recompile?). Accessing the asmx file for a faulty web service by IE shows the web service, but without the web methods. A look into the assemblies (using ILDASM) or checking trace information (trace.axd) showed everything to be normal
So what we are looking for now is: how can we trace/debug this kind of trouble to find what's causing it
I saw Matt Greer's question about a similar problem (2/3/2004), but I guess he is having the exception consistenly, while in our case it appears to be random
Any input would be welcome
Paul.