Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

ASMX Web Services and WCF Client Oddities


:P
On this page:

 

I’m still messing around with WCF and right now playing with accessing a variety of Web Services through a WCF client and then feeding the result back through COM Interop to an unmanaged application. There are a couple of disturbing things happening when using the default SvcUtil Web Service import functionality with Web Services depending on what type of methods are available on the existing ASMX Web Service.

 

I have a Web Service that includes a couple of support methods that allow passing in of DataSets by the client. The DataSet methods are optional and are meant only for an older application using FoxPro that passed this data. Since that app’s not used any more I thought I can safely get rid of that service method and remove the DataSet.

 

The single method looks like this:


[WebMethod(Description="Allows uploading of an invoice to the server using DataSet objects")]

public bool UploadInvoice( DataSet InvoiceDataSet )

 

What’s bizarre is that having a method in the service that returns or passes a DataSet drastically changes with SvcUtil generates. I’ve had lots of problems with consistency in this scenario and removing the DataSet method changed the behavior of the client overall.

 

A few things happen:

 

  • With the DataSet in the Web Service signatures I’ve had problems where SvcUtil will generate duplicate classes of the various message objects (ie. any complex parameters or return value types). It will double generate them. It’s inconsistent though – I have it working now but earlier today, with the same code SvcUtil would always generate duplicate message classes that I manually had to remove.

 

  • With no DataSet in the class the signatures bloat turning the simple operation signatures into complex Request/Response messages. Right – the Web Service proxy classes get much larger WITHOUT the DataSet in any of the signatures!

    The code generated states in a comment that SvcUtil must generate a Message Contract because the parameter type is not nillable. Whatever that means <s>. Check out these two generated classes below. The first one includes a single method that has DataSet input parameters. The second removes this method:



Quite a difference for REMOVING a single method to the service, huh?

 

  • Finally I’m using COM interop to let an unmanaged application access the Web Service. Since complex types are involved letting .NET do this is preferred vs. using the SOAP Toolkit or a custom solution that would involve manual XML parsing.

    So I’ve been passing the Proxy (the created Client instance) back over COM Interop to the client app and that works – the app sees the proxy and the service methods. However when I have the second scenario above (no DataSets) the Proxy methods don’t take simple parameters, but rather use Request/Response messages as parameters. In .NET this works correctly as the Client instance overrides the SOAP interface, but over COM the SOAP interface gets returned resulting in unusable parameters on the client. If I switch back and include the DataSet method again and regen the proxy, then everything works correctly – I get the proper method signatures all the back to the unmanaged client.

 

All of this makes me very nervous as it seems to be very inconsistent behavior. The SvcUtil hiccups, the odd behavior related to operations that include datasets (which incidentally looks to work BETTER than without them!) is not exactly confidence inspiring.

 

Granted this is a really fucked up scenario – COM Interop certainly is not terribly common anymore. DataSets are generally frowned upon in Web Services and for good reason. OTOH, I had a good reason to use them here because of interop concerns and they are used optionally. But I’m not sure I understand the behavior that occurs when the DataSet is removed from the Web service – that seems very backwards to me.

 

I suspect things are much smoother with using WCF to WCF operations which will become more common as time moves on, but right now I wonder if we’re not better off sticking to stock Web Service clients over WCF for pure Web Service front ends. At the end of the day – although more flexible – WCF is a bit more complex than using Web Service proxies and apparently more verbose. But looking forward I’m pretty sure that WCF will be the way to go and this is why I find myself here experimenting to see how things will go with these internal play services…

Posted in WCF  

The Voices of Reason


 

zproxy
November 29, 2006

# re: ASMX Web Services and WCF Client Oddities

As a workaround, do not remove the method, instead, make it obselete and/or make it throw and exception.

I think you have found a bug - a rare situation where the code generator gets confused.

Rick Strahl
November 29, 2006

# re: ASMX Web Services and WCF Client Oddities

How do I mark a method as obsolete in the service? Ultimately it's the metadata that SvcUtil is failing on not the actual compiled code that's executing...

# DotNetSlackers: ASMX Web Services and WCF Client Oddities


Daniel Roth
November 30, 2006

# re: ASMX Web Services and WCF Client Oddities

Could you please provide links to the WSDLs so that we can look into the issue? Thanks

Daniel Roth
WCF Metadata

SaaSMan
December 01, 2006

# re: ASMX Web Services and WCF Client Oddities

I think WCF clients are great when you need something not provided by the old wsdl.exe generated proxies such as the abilty to directly control soap headers in the request. Otherwise, I really don't see the point in upgrading, esp. legacy code, if its just doing basic http binding.

Daniel Roth
December 01, 2006

# re: ASMX Web Services and WCF Client Oddities

The following node of articles on MSDN provide a good analysis of when it does and does not make sense to migrate an ASMX code base to WCF:

http://msdn2.microsoft.com/en-us/library/ms730214.aspx

For any future web service developement, WCF is definately the way to go.

Daniel Roth

Rick Strahl
December 01, 2006

# re: ASMX Web Services and WCF Client Oddities

Daniel, I'll post both versions over the weekend. Right now only one is up there (which includes the DataSet method and looks pretty clean):

http://www.west-wind.com/webstoresandbox/service/WebStoreConsumerService.asmx

I'll post the other version when I get a minute this weekend.

Rick Strahl
December 01, 2006

# re: ASMX Web Services and WCF Client Oddities

Daniel, it makes sense what that article states, however I think that going forward you'd probably want to implement Web Services with WCF just to give the extra standards support and future proofing given that ASMX is probably done at this point <s>...

On the server side at least WCF isn't really any more work than ASMX (well it doesn't have to be, although the Contract/Implementation separation is probably new to most developers and implied). WCF just gives so many more choices without really making it any hard to create services although it does mean we have to spend a little time understanding all that can be tweaked. Powerful, but still relatively easy to use which in my book is a great combination!

I've had more issues with the WCF client against non-WCF clients though like the above. It's probably somthing minor that will work out as more scenarios are found as time goes by. I'm thinking it might just be easier to use a stock .NET 2.0 Web Service client when you know you're connecting to a standard Web service. There's not really much of a win using WCF for that since the server side determines protocol and options...

Rick Strahl
December 04, 2006

# re: ASMX Web Services and WCF Client Oddities

Ok, I've updated the site and created both services which can be found here:

http://www.west-wind.com/webstoresandbox/service/WebStoreConsumerService.asmx

http://www.west-wind.com/webstoresandbox/service/WebStoreConsumerService_withoutDs.asmx

As the name suggests the second service is the same as the first but removes just the single method that accepts a DataSet as input. The latter service proxy is not usable (well, maybe it is but it doesn't use simple parameters but message objects instead).

Vlad
February 10, 2009

# re: ASMX Web Services and WCF Client Oddities


Rick Strahl
February 10, 2009

# re: ASMX Web Services and WCF Client Oddities

@Vlad - that doesn't really solve any immediate problems because you have to have the contract Interface defined on the client still in order to use, which means you either have to generate it or implement it.

Ideally what we'd want is a way to dynamically invoke a Web Service without having to create anything client side (ie. Invoke("methodOnService",parm1,parm2)).

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024