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

About proxy classes generated when adding a web reference

P: n/a
Hi all,

I'm quite lost with how adding web references to a project creates proxy
classes.

I've developed a web service with two classes inside and that contains three
references to three DLLs. After building it up, I've deployed it on the web
server.

From my Windows application, I then add a web reference to that web service.
This web reference shows me two proxy classes (correct because I have two
classes in my webservice). Besides, I can access another proxy class that has
been automatically generated and that maps with a Reference to a DLL. What
about the other two DLLs? I'm using the three DLLs surely.

So, being logical, automatically should have been generated another
aditional two proxy classes from these DLLs. Why adding the web reference
only generates one proxy class mapped to a DLL and let the other two without
mapping and without access.

Any rational or logical explanation will be very helpful to me.
Nov 21 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hi Miguel,

When you create a web reference, VS.NET generates a web service proxy class
and optionally a bunch of other classes. These other classes reflect the
parameters and return types of your web methods. If a web method uses type
MyNamespace.XYZ in its parameters or return values, then a copy of that type
will be generated along with the proxy. Note that this copied type is not
the same type as the original type - it just has same name and same public
members but no private members.

To answer to your question about why some classes were not generated while
others were, without seeing the code, my guess is that the types that were
left out are not used as return values or parameters in the web methods.

Note that the XmlInclude attribute can be used to tell the XmlSerializer
about types that are not part of the static web method definition (i.e., if
a web method returns a base type but at runtime you return a derived type).

Regards,
Sami

"MIGUEL" <MI****@discussions.microsoft.com> wrote in message
news:0A**********************************@microsof t.com...
Hi all,

I'm quite lost with how adding web references to a project creates proxy
classes.

I've developed a web service with two classes inside and that contains three references to three DLLs. After building it up, I've deployed it on the web server.

From my Windows application, I then add a web reference to that web service. This web reference shows me two proxy classes (correct because I have two
classes in my webservice). Besides, I can access another proxy class that has been automatically generated and that maps with a Reference to a DLL. What
about the other two DLLs? I'm using the three DLLs surely.

So, being logical, automatically should have been generated another
aditional two proxy classes from these DLLs. Why adding the web reference
only generates one proxy class mapped to a DLL and let the other two without mapping and without access.

Any rational or logical explanation will be very helpful to me.


Nov 21 '05 #2

P: n/a
Thank you very much Sami.

You're rigth, as you tell me, types not used as return values or parameters
in the web methods aren't created as proxy classes. I don't use at all types
of the other two DLLs as return or parameter types. It's all clear for me now.

One more quetion: In order not to have DLLs deployed on the client side in
my Winforms application ("the thinner the client is the better"), I was
thinking about having the three DLLs deployed only on server side.

However, I don't know how to do it because I'm having problems. The
references on the web service are pointing to three DLLs located at different
places of the server. When I add these references and compile, in my bin
directory, are created the three DLLs. As they are pointing to another DLLs
located in another place in the disk (are redundant I think), I determine to
delete them from the "bin" directory. Nevertheless, it didn't work and gave
me an error telling that a DLL couldn't be found. It's a good idea to dop it
that way? I think having only the DLL of the web service in the "bin"
directory would be enough, wouldn't be? The DLLs are places in the correct
places, and th references are pointing to that places surely. I would like
your advice telling me if you see something strange going on there?

Besides, do you think it's a good idea to work in the Winforms application
only with instances of the proxy class generated? My goal is not to have
bussiness logic DLLs on the cleint side.

Regards and thanks again.
"Sami Vaaraniemi" wrote:
Hi Miguel,

When you create a web reference, VS.NET generates a web service proxy class
and optionally a bunch of other classes. These other classes reflect the
parameters and return types of your web methods. If a web method uses type
MyNamespace.XYZ in its parameters or return values, then a copy of that type
will be generated along with the proxy. Note that this copied type is not
the same type as the original type - it just has same name and same public
members but no private members.

To answer to your question about why some classes were not generated while
others were, without seeing the code, my guess is that the types that were
left out are not used as return values or parameters in the web methods.

Note that the XmlInclude attribute can be used to tell the XmlSerializer
about types that are not part of the static web method definition (i.e., if
a web method returns a base type but at runtime you return a derived type).

Regards,
Sami

"MIGUEL" <MI****@discussions.microsoft.com> wrote in message
news:0A**********************************@microsof t.com...
Hi all,

I'm quite lost with how adding web references to a project creates proxy
classes.

I've developed a web service with two classes inside and that contains

three
references to three DLLs. After building it up, I've deployed it on the

web
server.

From my Windows application, I then add a web reference to that web

service.
This web reference shows me two proxy classes (correct because I have two
classes in my webservice). Besides, I can access another proxy class that

has
been automatically generated and that maps with a Reference to a DLL. What
about the other two DLLs? I'm using the three DLLs surely.

So, being logical, automatically should have been generated another
aditional two proxy classes from these DLLs. Why adding the web reference
only generates one proxy class mapped to a DLL and let the other two

without
mapping and without access.

Any rational or logical explanation will be very helpful to me.


Nov 21 '05 #3

P: n/a
Comments inline:

"MIGUEL" <MI****@discussions.microsoft.com> wrote in message
news:A4**********************************@microsof t.com...
Thank you very much Sami.

You're rigth, as you tell me, types not used as return values or parameters in the web methods aren't created as proxy classes. I don't use at all types of the other two DLLs as return or parameter types. It's all clear for me now.
One more quetion: In order not to have DLLs deployed on the client side in
my Winforms application ("the thinner the client is the better"), I was
thinking about having the three DLLs deployed only on server side.

However, I don't know how to do it because I'm having problems. The
references on the web service are pointing to three DLLs located at different places of the server. When I add these references and compile, in my bin
directory, are created the three DLLs. As they are pointing to another DLLs located in another place in the disk (are redundant I think), I determine to delete them from the "bin" directory. Nevertheless, it didn't work and gave me an error telling that a DLL couldn't be found. It's a good idea to dop it that way? I think having only the DLL of the web service in the "bin"
directory would be enough, wouldn't be? The DLLs are places in the correct
places, and th references are pointing to that places surely. I would like
your advice telling me if you see something strange going on there?
That's how it works: when you create a reference to the DLLs from your web
service, the DLLs will be copied to the bin directory. You are supposed to
deploy the DLLs along with the web service DLL on the server, in the bin
directory.

Besides, do you think it's a good idea to work in the Winforms application
only with instances of the proxy class generated? My goal is not to have
bussiness logic DLLs on the cleint side.


The proxy classes are just simple data containers that give you type-safe
access to the web service parameter and return types. There is not much
business logic involved, so in my opinion it is perfectly ok.

Regards,
Sami
Nov 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.