The behavior you are seeing is the result of the way the XmlSerializer
deserialiezes xml. The XmlSerializer will simply set object members to
default values if they are missing from the xml document. It will fire an
event if an unknown attribute, element or node is discovered, but the asmx
handler ignores those events.

What this means is that any time you add a new argument to a webmethod, old
clients will still be able to get to your service and the extra parameter
will be set to null or its default. It also means that if your client throws
in some elements or attributes that your service doesn't expect, it will
silently ignore them.

If you want to insure that your clients are sending you an xml document that
conforms to either the implied or some explicit schema, you can do that with
a little work. See the July and August 2003 MSDN articles by Aaron Skonnard
and Dan Sullivan for a neat way to do validation of the xml and even extend
the validation to do business rules checking as well.

Bob

-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Brown
Sent: Wednesday, May 26, 2004 1:12 PM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Replacing web service components

Can someone please help me understand how .Net handles replacing components,
specifically web services...

I have a web service that is currently in production. I now need to add a
new parameter to the function. I found out that you can't overload the
function in a web service, so in my test environment, I just added the new
parameter, and expected that my test client would break. It didn't break, so
I figured that the old web service component must be in memory somewhere. I
rebooted my test server, and again expected the test client to fail because
it wasn't sending the new parameter. Again it didn't fail. To make a long
story short, when I change the parameters (even when I add the new one in
the middle of the param list), everything still keeps using the old version
until they import the new wsdl file. If I change the function name however,
then everything using the service breaks. That is why I am confused If a
copy is stored somewhere, then why would it break when I change the function
name?

I guess what I am really trying to figure out is if I add the new parameter
to the existing function, will the old clients eventually break, or will
they continue to use the old code until they update their wsdl. Would I be
better off just creating a new function with a new name? I would like to
avoid changing the name of the function if possible, especially if I have to
keep changing the name every time I change the signature of the function.

Thanks,
Shawn Brown

===================================
This list is hosted by DevelopMentorR  http://www.develop.com
Some .NET courses you may be interested in:

NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls

View archives and manage your subscription(s) at http://discuss.develop.com

===================================
This list is hosted by DevelopMentor�  http://www.develop.com
Some .NET courses you may be interested in:

NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to