By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 1,260 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

Need to test a .Net dll using data that was sent to a WebService

P: n/a
Hi folks,

I have a WebService that simply acts as a thin wrapper to a .Net dll.

Literally almost zero code in the WebService.

Parameters passed to the WebService are simply used as parameters to
methods on the dll, and all parameters to my web methods are strings.
(The strings, just for further info, contain XML).

In the WebService by way of some diagnostic code I perform an
XmlDocument.Save() prior to calling my dll (to store the "string" in an
XML document), the theory being that I can then do an XmlDocument.Load()
on any file to diagnose a problem in my dll should a request to a
WebService fail. So far so good.. (well actually no)

Now here's the thing.. I had a client app (iexplorer) make a call the
WebService and that method failed, and on identifying which XML document
on my server failed, I loaded it up and tested my dll directly and it
worked. So obviously this means that some encoding issue between "being
sent over the wire from a browser" and "retreived as a string from a
file" is causing a discrepancy in testing since they're different input
parameters and are leading to different results. I know it is infact
this because when I do an XmlDocument.Load() in my WebService before
calling my dll so they have the SAME input data the dll also works from
the WebService. Argh.

So my question is: How can I test my WebService and DLL so that they
both use the same input data. How do I effectively test my dll so the
string I pass to a particular method is the string "as it was recieved
over the wire" by my WebService method.

Hope I've been clear?

Pebble
Sep 13 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"Pebble" <af***@23o.1f.co.ukwrote in message
news:ee***********@custnews.inweb.co.uk...
Hi folks,

I have a WebService that simply acts as a thin wrapper to a .Net dll.

Literally almost zero code in the WebService.

Parameters passed to the WebService are simply used as parameters to
methods on the dll, and all parameters to my web methods are strings.
(The strings, just for further info, contain XML).

In the WebService by way of some diagnostic code I perform an
XmlDocument.Save() prior to calling my dll (to store the "string" in an
XML document), the theory being that I can then do an XmlDocument.Load()
on any file to diagnose a problem in my dll should a request to a
WebService fail. So far so good.. (well actually no)

Now here's the thing.. I had a client app (iexplorer) make a call the
WebService and that method failed, and on identifying which XML document
on my server failed, I loaded it up and tested my dll directly and it
worked. So obviously this means that some encoding issue between "being
sent over the wire from a browser" and "retreived as a string from a
file" is causing a discrepancy in testing since they're different input
parameters and are leading to different results. I know it is infact
this because when I do an XmlDocument.Load() in my WebService before
calling my dll so they have the SAME input data the dll also works from
the WebService. Argh.
Unless you're validating your input parameters against a schema, or at least
testing them for being well-formed, I would not use XmlDocument.Save for
diagnostic purposes. Your clients are sending you strings which, if all is
well, will be well-formed XML. You should save them as strings, in case
there's something wrong with the input.

Doing this might show you what your problem is, as you won't have
XmlDocument intervening between what your web service receives and what your
DLL receives.

John
Sep 13 '06 #2

P: n/a
* John Saunders wrote:
Unless you're validating your input parameters against a schema, or at least
testing them for being well-formed, I would not use XmlDocument.Save for
diagnostic purposes. Your clients are sending you strings which, if all is
well, will be well-formed XML. You should save them as strings, in case
there's something wrong with the input.

Doing this might show you what your problem is, as you won't have
XmlDocument intervening between what your web service receives and what your
DLL receives.
So then I guess my question is how do I store a string so that when I
read it, I can be sure it is IDENTICAL to how it was PRIOR to storing it.
Sep 14 '06 #3

P: n/a
"Pebble" <af***@23o.1f.co.ukwrote in message
news:ee***********@custnews.inweb.co.uk...
>* John Saunders wrote:
>Unless you're validating your input parameters against a schema, or at
least
testing them for being well-formed, I would not use XmlDocument.Save for
diagnostic purposes. Your clients are sending you strings which, if all
is
well, will be well-formed XML. You should save them as strings, in case
there's something wrong with the input.

Doing this might show you what your problem is, as you won't have
XmlDocument intervening between what your web service receives and what
your
DLL receives.

So then I guess my question is how do I store a string so that when I
read it, I can be sure it is IDENTICAL to how it was PRIOR to storing it.
TextWriter.Write(string);
TextReader.Read(string);

This isn't difficult. You just need to remove any unnecessary layers between
the string and your code and the storage medium.

John
Sep 14 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.