Class as a Function Parameter...

[Bob Erwin]

Hello,

I'm having a problem with a custom object that I have setup in a Utilities
DLL for my application call UserInfo. I use this custom Object in my main
application, and wanted to pass this object to my Web Service, so I have
included the Utilities DLL as part of my Web Service As well and setup the
function to accept the object.

However, the intellisence in my main application says that I can't convert
my UserInfo object to the WebService's UserInfo Object, even though it is
using the same backend DLL. Also the UserInfo Object is setup Serializable.

Does that make sense...it is pretty hard to explain and even harder to
search deja on.

Thanks a lot for your help,
Bob

 

[Bob Erwin]

Hello,

I think I figured this out, but just wanted to make sure I'm doing this in
the most efficient way. I'm using the whole XMLSerialization and am just
passing the xmlstring value to the web service...here is my code.

Host Application
sb = New StringBuilder
sw = New StringWriter(sb)
xtw = New XmlTextWriter(sw)
oSerializer = New XmlSerializer(GetType(UserInfo))

oSerializer.Serialize(xtw, oUserInfo)
xtw.Close()
XMLUserInfo = sb.ToString

Web Service:
sr = New StringReader(XMLUserInfo)
oDeSerializer = New XmlSerializer(GetType(UserInfo))
oUserInfo = CType(oDeSerializer.Deserialize(sr), UserInfo)

Does that look about right then?

Thanks for your help!
Bob

 

[Andrew Hopper]

You may want to look at my article on how to use "shared types" assemblies
with ASP.NET Web Services:
http://dotnetified.com/PermaLink.aspx?guid=abaf08b3-1abd-4dae-be05-23b733ff3c5d

HTH!
-Andy Hopper
http://www.dotnetified.com

 

[Sami Vaaraniemi]

You may want to look at my article on how to use "shared types" assemblies
with ASP.NET Web Services:
http://dotnetified.com/PermaLink.aspx?guid=abaf08b3-1abd-4dae-be05-23b733ff3c5d

HTH!
-Andy Hopper
http://www.dotnetified.com

You're probably aware of this already, but I think it's still worth pointing
it out. If you share types as described in the article you get the worst of
both worlds: you get tight coupling combined with the inefficiency of web
services. If you want tight coupling, why not use remoting and avoid the web
services overhead altogether?

Sami
www.capehill.net

 

[Andrew Hopper]

Well, that's not entirely true.

As long as you are careful about maintaining backwards compatibility in your
types (i.e., don't add new properties that are required), the XML serializer
does a good job at performing impedance matching between versions. We have
several apps in the field that were compiled against a 1.0 version of a
types assembly that are calling Web Services using newer revisions. The
abstraction is there; we're just making the client developer's jobs easier
by providing them with an assembly that just happens to contain a set of
types that look suspiciously like those on the server-side.

-Andy

 

[Sami Vaaraniemi]

Well, that's not entirely true.

As long as you are careful about maintaining backwards compatibility in your
types (i.e., don't add new properties that are required), the XML serializer
does a good job at performing impedance matching between versions. We have
several apps in the field that were compiled against a 1.0 version of a
types assembly that are calling Web Services using newer revisions. The
abstraction is there; we're just making the client developer's jobs easier
by providing them with an assembly that just happens to contain a set of
types that look suspiciously like those on the server-side.

-Andy

Agreed, you do have a point here. The coupling is not as tight as it is with
remoting because of the XML serialization step. I jumped to a hasty
conclusion.

You need to take care though - giving out assemblies instead of just relying
on WSDL may complicate things in the long run. Delivering a new assembly to
your consumers every time you publish new functionality is painful compared
to telling them to generate new proxies against the WSDL.

Sami
www.capehill.net

Sami
www.capehill.net

 

[Andrew Hopper]

I completely agree. I would only recommend the shared types assembly in a
couple of scenarios. One of which is where you have a set of WebServices
that may be invoked by a single third-party app, in which case you might
consider deploying pre-generated proxies along with the types as an SDK to
make third-party developers' lives easier. Another is when you have control
over client development - intranet apps, for example. My main point was that
sometimes this "firmly coupled" approach can find a sweet spot in the
productivity vs. flexibility curve.

-Andy