WebServices in .Net 2.0 vs. WebServices in .Net 1.1

WebServices in .Net 2.0 vs. WebServices in .Net 1.1

Post by RnJlZGVyaW » Fri, 12 May 2006 15:00:01

I'm currently developing a windows form application, which should be able to
communicate with a couple of WebServices. The Webservices are not created by
me or my company and also not in .net but WebMethods (Java I suppose).
The first Issue that I have is when instantiating one of webservices I get a
"Method myMethod can not be reflected" error message and when drilling down
the exception hierarchy I find: InnerException = {"'date' is an invalid
value for the SoapElementAttribute.DataType property. The property may only
be specified for primitive types."}.

Curios as I am I tried the exact same thing but this time I used VS 2003
instead of VS 2005 (above) and then it works... (At least this far.)
Can anyone explain this and point me to a resolution?

Regards Frederik

WebServices in .Net 2.0 vs. WebServices in .Net 1.1

Post by Tat Sea » Tue, 22 Aug 2006 19:45:34

I am facing the same problem. Not a single search engine can get the answer. Where are all the MS folks?

Posted from http://www.yqcomputer.com/ : the website based NNTP reader.


WebServices in .Net 2.0 vs. WebServices in .Net 1.1

Post by Pablo Cibr » Tue, 22 Aug 2006 23:29:30


I am not sure, but that problem may happen due an incompatibility between
the web service proxies generated in .NET 1.1 and the proxies generated in
.NET 2.0.
VS automaticallty generates some code to consume the web services, if that
code was compiled using .NET 1.1 (Using some valid xml serialization rules
that are no longer valid in .NET 2.0), you will have problems to use the
same code in a .NET 2.0 application.

Pablo Cibraro.

WebServices in .Net 2.0 vs. WebServices in .Net 1.1

Post by QUtK » Thu, 24 Aug 2006 01:03:01

I can't help you here, but I'm getting exactly the same error when trying to
connect to one of our own webservices (produced via Progress 4gl/openedge
running on HP-UX 11 box).

Worked fine with v1.1, but v2 gets the error shown above.

It seems that we get the error when the offending field is winthin a complex

Previously it converted them to datetime before presenting them to Dot Net
c# client, but now goes pop.