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

Have to use web reference?

P: n/a
Do I have to use a web reference to access use a remote web reference?
I can't seem to just use the proxy generated by my web services
project, because that one never calls the remote service, its always a
local one.

Dave

Jun 1 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
<Da*********@gmail.comwrote in message
news:11**********************@p47g2000hsd.googlegr oups.com...
Do I have to use a web reference to access use a remote web reference?
I can't seem to just use the proxy generated by my web services
project, because that one never calls the remote service, its always a
local one.
A web service project does not generate a proxy, so I'm not sure what you
are referring to.

Why do you not want to use a web reference?
--
John Saunders [MVP]


Jun 2 '07 #2

P: n/a
On Jun 1, 9:33 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
<Davidher...@gmail.comwrote in message

news:11**********************@p47g2000hsd.googlegr oups.com...
Do I have to use a web reference to access use a remote web reference?
I can't seem to just use the proxy generated by my web services
project, because that one never calls the remote service, its always a
local one.

A web service project does not generate a proxy, so I'm not sure what you
are referring to.

Why do you not want to use a web reference?
--
John Saunders [MVP]
Visual studio web service projects do generate a
webServiceName.asmx.cs proxy, which can be used to create and debug
web service functions. But for some reason I can just change a single
setting to get that proxy to use the real service. I know it must be
meant to do it that way, but its hard as hell to find the setting. The
other way to generate a proxy is to add a web reference. behind the
scenes a proxy is created for that web service, so that visual studio
can pretend a local class just like that web service exists. The
problem is, I can't use just a web reference, because if I ever want
to make a change, I have to recompile the web service, upload it to
the site, and then update the web references. In addition, the complex
types returned by a web service are not the same class type as the
original classes that were used to make them! so If I write a function
that is "public MyObject GetMyObject(int ID)" the MyObject I used to
make it, and the one returned can't be used interchangebly!

Its got to be such an easy fix. somebody out there must know.
somebody?
Jun 2 '07 #3

P: n/a
<Da*********@gmail.comwrote in message
news:11**********************@p47g2000hsd.googlegr oups.com...
On Jun 1, 9:33 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
><Davidher...@gmail.comwrote in message

news:11**********************@p47g2000hsd.googleg roups.com...
Do I have to use a web reference to access use a remote web reference?
I can't seem to just use the proxy generated by my web services
project, because that one never calls the remote service, its always a
local one.

A web service project does not generate a proxy, so I'm not sure what you
are referring to.

Why do you not want to use a web reference?
--
John Saunders [MVP]

Visual studio web service projects do generate a
webServiceName.asmx.cs proxy, which can be used to create and debug
web service functions.
Ok, here's the terminology problem. The file you refer to isn't the proxy.
It _is_ the web service implementation.

I think there's some fundamental confusion here. Can you please give us some
details of what you're trying to accomplish? In particular, it sometimes
helps when discussing distributed systems, to provide names for the various
entities. These need not be the real names, just things like Service1 and
Consumer1 instead of "the remote service" and "the consumer".
--
John Saunders [MVP]
Jun 2 '07 #4

P: n/a
On Jun 2, 10:27 am, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
<Davidher...@gmail.comwrote in message

news:11**********************@p47g2000hsd.googlegr oups.com...
On Jun 1, 9:33 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
<Davidher...@gmail.comwrote in message
>news:11**********************@p47g2000hsd.googleg roups.com...
Do I have to use a web reference to access use a remote web reference?
I can't seem to just use the proxy generated by my web services
project, because that one never calls the remote service, its always a
local one.
A web service project does not generate a proxy, so I'm not sure what you
are referring to.
Why do you not want to use a web reference?
--
John Saunders [MVP]
Visual studio web service projects do generate a
webServiceName.asmx.cs proxy, which can be used to create and debug
web service functions.

Ok, here's the terminology problem. The file you refer to isn't the proxy.
It _is_ the web service implementation.

I think there's some fundamental confusion here. Can you please give us some
details of what you're trying to accomplish? In particular, it sometimes
helps when discussing distributed systems, to provide names for the various
entities. These need not be the real names, just things like Service1 and
Consumer1 instead of "the remote service" and "the consumer".
--
John Saunders [MVP]
Thanks John.

I'll try to explain briefly. Well, I'm trying to create a web service
to to authentication and upload files, for example, from a .net
desktop application. One area that is especially giving me trouble is
the file uploading. I call a web service function "public MyFile
NewMyFile(..., string uploadPath, bool overwrite, ViewPermissionEnum
viewPermission)" I use the MyFile class to get all the information
from the server I need to start uploading. So, I want to make sure the
file uploading works, not only locally but on the real server. I
created a web services project and several other projects for client
apps. The way I first started coding it was to directly reference the
project's web service implementation, VideoService1. I didn't make a
web reference(maybe this was my first problem). Now, what I need to
do, is deploy the web service, which I've done, and then be able to
use the same code I've been testing locally to test it on the server.
I just need to change the connection string from "localhost/
VideoService1" to "<Domain_Name>/VideoService1". Right now I'm using
"<Domain_Name>/VideoService1" and I've put redirected the Domain_Name
to the localhost address 127.0.0.1. That works somewhat but then I
can't get the web service to recognize MyFile as the same MyFile I
used to create the web service. No matter what tricks I try to use. It
always thinks the MyFile that is returned by the web service is of
type "VideoServicesWebReference.MyFile" and not
"VideoServices.MyFile". I thought the proxy took care of the xml
serialization and deserialization, assuming I designed the class
correctly. How do I get it to recognize the MyFile as the same MyFile
I used to create the web service, and am I setting up my web service
correctly now? I think I'm at least getting closer.

Thanks
Dave

Jun 2 '07 #5

P: n/a
<Da*********@gmail.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...
On Jun 2, 10:27 am, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
I'll try to explain briefly. Well, I'm trying to create a web service
....
The way I first started coding it was to directly reference the
project's web service implementation, VideoService1. I didn't make a
web reference(maybe this was my first problem).
Indeed, this was your first problem.

NEVER do this. When working on the client, you should treat the service as a
black box, with "holes" drilled into it which are the "shape" of the WSDL.

None of those holes exposes the web service's implementation, so you should
never use it. That assembly is for the use of ASP.NET in hosting your web
service. It is not for the use of the client.

You may have been tempted to do this by the fact that, when you use a web
reference, the proxy classes are not the same as the implementation classes.
They're not supposed to be! Again, the implementation and the contract are
totally separated from each other in web services.

Please try again, using a web reference in your client project. Trust me
when I say that you do _not_ want the client to use the web service
implementation, in any way at all. One of the first web service projects I
worked on had been badly messed up by a person who not only didn't
understand the client/service distinction, he didn't understand layers at
all. He the web service exposed the functions of a third-party library, so
we had one assembly with a method called "Method1", which was the
third-party method (using P/Invoke, to make it worse). Then we had a wrapper
library with a method called "Method1", but with a simpler interface. Then
we had the web service, which had a web method called "Method1". Finally, we
had the client code, which had a proxy method called "Method1".

Things got even worse when the code started dealing with the return values
from Method1. Yes, there were four different versions of MyClass1...

Then there were unit tests, some of which were meant to be testing one
"Method1", but were using another "Method1" to do it with!

I recommend that you use a web reference and maintain a thick wall between
the client and the server.
--
John Saunders [MVP]
Jun 2 '07 #6

P: n/a
On Jun 2, 5:10 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
<Davidher...@gmail.comwrote in message

news:11**********************@p77g2000hsh.googlegr oups.com...
On Jun 2, 10:27 am, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
I'll try to explain briefly. Well, I'm trying to create a web service
...
The way I first started coding it was to directly reference the
project's web service implementation, VideoService1. I didn't make a
web reference(maybe this was my first problem).

Indeed, this was your first problem.

NEVER do this. When working on the client, you should treat the service as a
black box, with "holes" drilled into it which are the "shape" of the WSDL.

None of those holes exposes the web service's implementation, so you should
never use it. That assembly is for the use of ASP.NET in hosting your web
service. It is not for the use of the client.

You may have been tempted to do this by the fact that, when you use a web
reference, the proxy classes are not the same as the implementation classes.
They're not supposed to be! Again, the implementation and the contract are
totally separated from each other in web services.

Please try again, using a web reference in your client project. Trust me
when I say that you do _not_ want the client to use the web service
implementation, in any way at all. One of the first web service projects I
worked on had been badly messed up by a person who not only didn't
understand the client/service distinction, he didn't understand layers at
all. He the web service exposed the functions of a third-party library, so
we had one assembly with a method called "Method1", which was the
third-party method (using P/Invoke, to make it worse). Then we had a wrapper
library with a method called "Method1", but with a simpler interface. Then
we had the web service, which had a web method called "Method1". Finally, we
had the client code, which had a proxy method called "Method1".

Things got even worse when the code started dealing with the return values
from Method1. Yes, there were four different versions of MyClass1...

Then there were unit tests, some of which were meant to be testing one
"Method1", but were using another "Method1" to do it with!

I recommend that you use a web reference and maintain a thick wall between
the client and the server.
--
John Saunders [MVP]
Thank you very much. Now I think I've got it. And I gather that the
return type is not actually supposed to be castable into the original
class used to create it. So, I'll have to manually do it but something
like"myFile.id = returnedMyFile.id; myFile.url = returnMyFile.url".

Dave

Jun 2 '07 #7

P: n/a
<Da*********@gmail.comwrote in message
news:11**********************@q69g2000hsb.googlegr oups.com...
On Jun 2, 5:10 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
><Davidher...@gmail.comwrote in message

news:11**********************@p77g2000hsh.googleg roups.com...
On Jun 2, 10:27 am, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
I'll try to explain briefly. Well, I'm trying to create a web service
...
The way I first started coding it was to directly reference the
project's web service implementation, VideoService1. I didn't make a
web reference(maybe this was my first problem).

Indeed, this was your first problem.

NEVER do this. When working on the client, you should treat the service
as a
black box, with "holes" drilled into it which are the "shape" of the
WSDL.

None of those holes exposes the web service's implementation, so you
should
never use it. That assembly is for the use of ASP.NET in hosting your web
service. It is not for the use of the client.

You may have been tempted to do this by the fact that, when you use a web
reference, the proxy classes are not the same as the implementation
classes.
They're not supposed to be! Again, the implementation and the contract
are
totally separated from each other in web services.

Please try again, using a web reference in your client project. Trust me
when I say that you do _not_ want the client to use the web service
implementation, in any way at all. One of the first web service projects
I
worked on had been badly messed up by a person who not only didn't
understand the client/service distinction, he didn't understand layers at
all. He the web service exposed the functions of a third-party library,
so
we had one assembly with a method called "Method1", which was the
third-party method (using P/Invoke, to make it worse). Then we had a
wrapper
library with a method called "Method1", but with a simpler interface.
Then
we had the web service, which had a web method called "Method1". Finally,
we
had the client code, which had a proxy method called "Method1".

Things got even worse when the code started dealing with the return
values
from Method1. Yes, there were four different versions of MyClass1...

Then there were unit tests, some of which were meant to be testing one
"Method1", but were using another "Method1" to do it with!

I recommend that you use a web reference and maintain a thick wall
between
the client and the server.
--
John Saunders [MVP]

Thank you very much. Now I think I've got it. And I gather that the
return type is not actually supposed to be castable into the original
class used to create it. So, I'll have to manually do it but something
like"myFile.id = returnedMyFile.id; myFile.url = returnMyFile.url".
Actually, you should not use the original class at all on the client.
Period. What's wrong with using the proxy class?
--
John Saunders [MVP]
Jun 2 '07 #8

P: n/a
On Jun 2, 6:27 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
<Davidher...@gmail.comwrote in message

news:11**********************@q69g2000hsb.googlegr oups.com...
On Jun 2, 5:10 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
<Davidher...@gmail.comwrote in message
>news:11**********************@p77g2000hsh.googleg roups.com...
On Jun 2, 10:27 am, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
I'll try to explain briefly. Well, I'm trying to create a web service
...
The way I first started coding it was to directly reference the
project's web service implementation, VideoService1. I didn't make a
web reference(maybe this was my first problem).
Indeed, this was your first problem.
NEVER do this. When working on the client, you should treat the service
as a
black box, with "holes" drilled into it which are the "shape" of the
WSDL.
None of those holes exposes the web service's implementation, so you
should
never use it. That assembly is for the use of ASP.NET in hosting your web
service. It is not for the use of the client.
You may have been tempted to do this by the fact that, when you use a web
reference, the proxy classes are not the same as the implementation
classes.
They're not supposed to be! Again, the implementation and the contract
are
totally separated from each other in web services.
Please try again, using a web reference in your client project. Trust me
when I say that you do _not_ want the client to use the web service
implementation, in any way at all. One of the first web service projects
I
worked on had been badly messed up by a person who not only didn't
understand the client/service distinction, he didn't understand layers at
all. He the web service exposed the functions of a third-party library,
so
we had one assembly with a method called "Method1", which was the
third-party method (using P/Invoke, to make it worse). Then we had a
wrapper
library with a method called "Method1", but with a simpler interface.
Then
we had the web service, which had a web method called "Method1". Finally,
we
had the client code, which had a proxy method called "Method1".
Things got even worse when the code started dealing with the return
values
from Method1. Yes, there were four different versions of MyClass1...
Then there were unit tests, some of which were meant to be testing one
"Method1", but were using another "Method1" to do it with!
I recommend that you use a web reference and maintain a thick wall
between
the client and the server.
--
John Saunders [MVP]
Thank you very much. Now I think I've got it. And I gather that the
return type is not actually supposed to be castable into the original
class used to create it. So, I'll have to manually do it but something
like"myFile.id = returnedMyFile.id; myFile.url = returnMyFile.url".

Actually, you should not use the original class at all on the client.
Period. What's wrong with using the proxy class?
--
John Saunders [MVP]
Hmmm. I guess you're right. I'm just so used to building helper
functions into the object itself. Such as the ability for the file to
upload itself.

I finally understand now. :) Thanks again.

Dave

Jun 2 '07 #9

P: n/a
<Da*********@gmail.comwrote in message
news:11**********************@p47g2000hsd.googlegr oups.com...
On Jun 2, 6:27 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
><Davidher...@gmail.comwrote in message

news:11**********************@q69g2000hsb.googleg roups.com...
On Jun 2, 5:10 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
<Davidher...@gmail.comwrote in message
>>news:11**********************@p77g2000hsh.google groups.com...
On Jun 2, 10:27 am, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
I'll try to explain briefly. Well, I'm trying to create a web
service
...
The way I first started coding it was to directly reference the
project's web service implementation, VideoService1. I didn't make a
web reference(maybe this was my first problem).
>Indeed, this was your first problem.
>NEVER do this. When working on the client, you should treat the
service
as a
black box, with "holes" drilled into it which are the "shape" of the
WSDL.
>None of those holes exposes the web service's implementation, so you
should
never use it. That assembly is for the use of ASP.NET in hosting your
web
service. It is not for the use of the client.
>You may have been tempted to do this by the fact that, when you use a
web
reference, the proxy classes are not the same as the implementation
classes.
They're not supposed to be! Again, the implementation and the contract
are
totally separated from each other in web services.
>Please try again, using a web reference in your client project. Trust
me
when I say that you do _not_ want the client to use the web service
implementation, in any way at all. One of the first web service
projects
I
worked on had been badly messed up by a person who not only didn't
understand the client/service distinction, he didn't understand layers
at
all. He the web service exposed the functions of a third-party
library,
so
we had one assembly with a method called "Method1", which was the
third-party method (using P/Invoke, to make it worse). Then we had a
wrapper
library with a method called "Method1", but with a simpler interface.
Then
we had the web service, which had a web method called "Method1".
Finally,
we
had the client code, which had a proxy method called "Method1".
>Things got even worse when the code started dealing with the return
values
from Method1. Yes, there were four different versions of MyClass1...
>Then there were unit tests, some of which were meant to be testing one
"Method1", but were using another "Method1" to do it with!
>I recommend that you use a web reference and maintain a thick wall
between
the client and the server.
--
John Saunders [MVP]
Thank you very much. Now I think I've got it. And I gather that the
return type is not actually supposed to be castable into the original
class used to create it. So, I'll have to manually do it but something
like"myFile.id = returnedMyFile.id; myFile.url = returnMyFile.url".

Actually, you should not use the original class at all on the client.
Period. What's wrong with using the proxy class?
--
John Saunders [MVP]

Hmmm. I guess you're right. I'm just so used to building helper
functions into the object itself. Such as the ability for the file to
upload itself.

I finally understand now. :) Thanks again.
Right. This is one of the things that many new Web Services developers get
confused about. I think it's because Visual Studio.NET has made Web Services
_too_ easy!

The proxy class and the "real" class are largely unrelated. This is a
consequence of the Web Services infrastructure, and the fact that Web
Services are a platform-neutral facility.

Consider: a recent poster asked how to code his client so that it could
handle a class being returned from his web service. The problem was that he
had added an ArrayList property to the class.

The right question to ask is, "how would I handle this ArrayList in Java (or
Perl, or VBScript, or JavaScript, ...". The answer is, "you don't, because
ArrayList is specific to the .NET platform, and the other platforms don't
have it". They _do_ have arrays, though, so you should use arrays instead.
Even there, I suppose you could have a problem with a platform which does
not support variable-length arrays...

It all comes down to the fact that Web Services transmit and receive XML,
which is described by XML Schemas, which are described by a WSDL. Microsoft
has cleverly made this less painful in the .NET world, but part of what
makes it easy to use Web Services in .NET is a matter of hiding a lot of
magic; in fact, of hiding the fact that there _is_ magic.

Unfortunately, once the magic runs out, you can be left with little
recourse, as you may not have known there was any magic at all.
--
John Saunders [MVP]
Jun 2 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.