Reproduce what? My web service runs fine currently. Client side asked for
data pertaining to the Soap response I send back, so I want to capture the
Soap message. It seemed like WSE with trace enabled would do the trick on my
test client page without having to put code in web service directly.

doug

"John Saunders [MVP]" wrote:

"doug" <dmartin (AT) newsgroups (DOT) nospam> wrote

Wow. If you ever posted that, then I forgot it.

Adding WSE just for tracing is a bit of overkill!
--
John Saunders [MVP]

"doug" <dmartin (AT) newsgroups (DOT) nospam> wrote

Wow. If you ever posted that, then I forgot it.

Adding WSE just for tracing is a bit of overkill!
--
John Saunders [MVP]

Overkill? Maybe. We are in serious testing phase and client side says they
are having and issue, please email the Soap response I created to them. From
my side, not having had any .Net formal .Net training but have many years of
VB and ASP XML based webservices, this is my first Soap experience, and MS
was clever in hiding the implemtation details so code doesn't care how it may
have been invoked - knowing how to capture Soap request/response seems like a
normal thing to want. If that makes it overkill, that was a design choice
made by MS not me.

doug

"John Saunders [MVP]" wrote:

Overkill? Maybe. We are in serious testing phase and client side says they
are having and issue, please email the Soap response I created to them. From
my side, not having had any .Net formal .Net training but have many years of
VB and ASP XML based webservices, this is my first Soap experience, and MS
was clever in hiding the implemtation details so code doesn't care how it may
have been invoked - knowing how to capture Soap request/response seems like a
normal thing to want. If that makes it overkill, that was a design choice
made by MS not me.

doug

"John Saunders [MVP]" wrote:

"doug" <dmartin (AT) newsgroups (DOT) nospam> wrote

Ok, I didn't know the background.

BTW, the implementation details they're hiding aren't the sort that would
let you easily figure out how to capture the request/response. It's more
complicated than that.

When you get some time, you may want to look at
http://support.microsoft.com/kb/320438, which is an article with web service
sample code in a download. It includes a SoapTraceExtension sample. I have
used one of these to trace request and response messages in production code.
I based it on another MSDN article I can't find any longer.

Another reason to look at the SoapTraceExtension sample is that it will at
least give you an idea of how complicated an environment you're actually
working in. You'll be glad that Microsoft hid the implementation details
from you!
--
John Saunders [MVP]

"doug" <dmartin (AT) newsgroups (DOT) nospam> wrote

Ok, I didn't know the background.

BTW, the implementation details they're hiding aren't the sort that would
let you easily figure out how to capture the request/response. It's more
complicated than that.

When you get some time, you may want to look at
http://support.microsoft.com/kb/320438, which is an article with web service
sample code in a download. It includes a SoapTraceExtension sample. I have
used one of these to trace request and response messages in production code.
I based it on another MSDN article I can't find any longer.

Another reason to look at the SoapTraceExtension sample is that it will at
least give you an idea of how complicated an environment you're actually
working in. You'll be glad that Microsoft hid the implementation details
from you!
--
John Saunders [MVP]

I do not believe a requirement (in my case a post code/test requirement) to
capture Soap traffic is asking for all that much. I don't think asking for a
simple method that gets invoked while receiving and sending what is the
actual message sent up and down the line is an over the top request. It
apparently isn't there (except maybe as 3rd party add-on).

I have reviewed samples on web service side and client side, mostly for pre
MSVS 2005 where it seems a lot has changed. Apparently the now depreciated
Soap SDK worked. It has been superceded by WSE 1, WSE1.1, WSE2, and WSE3.
These don't seem to work. I appreciate digging into the bowels can be
hard/difficult. It was easier in ASP days. Now it is easier to code just
the work you want without coding so much housekeeping. Fine. But it
shouldn't be that complex either. Enter WSE. Previously it was suggested I
look at WSE. I found WSE v3 and it loaded fine (earlier versions are not
correct for my configuration). I configured it, used it to update my client
sde test aspx page's web.config, my code matches the sample code, and I
believe I've done all configuration tasks documented. The WSE Soap Tracing
isn't working. Searches show that others have hit the same wall I have. It
would appear MS provided a tool to capture Soap messages cleanly and somewhat
easily, yet it doesn't work, and doesn't say that it failed or even tried.
So the tool is not working or it use isn't fully documented.

I'm hoping someone can resolve my client side ASPX WSE3 Framework v2 .Net
2005 issue that seems to predominently involve changes to web.config.



"John Saunders [MVP]" wrote:

I do not believe a requirement (in my case a post code/test requirement) to
capture Soap traffic is asking for all that much. I don't think asking for a
simple method that gets invoked while receiving and sending what is the
actual message sent up and down the line is an over the top request. It
apparently isn't there (except maybe as 3rd party add-on).

I have reviewed samples on web service side and client side, mostly for pre
MSVS 2005 where it seems a lot has changed. Apparently the now depreciated
Soap SDK worked. It has been superceded by WSE 1, WSE1.1, WSE2, and WSE3.
These don't seem to work. I appreciate digging into the bowels can be
hard/difficult. It was easier in ASP days. Now it is easier to code just
the work you want without coding so much housekeeping. Fine. But it
shouldn't be that complex either. Enter WSE. Previously it was suggested I
look at WSE. I found WSE v3 and it loaded fine (earlier versions are not
correct for my configuration). I configured it, used it to update my client
sde test aspx page's web.config, my code matches the sample code, and I
believe I've done all configuration tasks documented. The WSE Soap Tracing
isn't working. Searches show that others have hit the same wall I have. It
would appear MS provided a tool to capture Soap messages cleanly and somewhat
easily, yet it doesn't work, and doesn't say that it failed or even tried.
So the tool is not working or it use isn't fully documented.

I'm hoping someone can resolve my client side ASPX WSE3 Framework v2 .Net
2005 issue that seems to predominently involve changes to web.config.



"John Saunders [MVP]" wrote:

"doug" <dmartin (AT) newsgroups (DOT) nospam> wrote

That's not true. The sample I cited had what you need with
SoapTraceExtension.

Well, no. The SOAP SDK was superseded (for .NET code) by ASP.NET Web
Services. WSE is a set of extensions to ASP.NET Web Services. It has also
been superseded, this time by Windows Communications Framework, which is
part of .NET 3.0.


You may not realize it, but you are greatly complicating your life by using
WSE. Its features are MUCH more than you seem to need, and that may be the
problem you're having with web.config.

I don't know who recommended WSE, or why, but I would reccomend against WSE
unless you need to use standards like WS-Addressing, WS-ReliableMessaging,
etc.

--
John Saunders [MVP]