«

I am running a Web Services application on a Windows 2003 Server
(specifically, SBS 2003, SP1). When I query the Web Service for a WSDL
file, I find that the WSDL is advertising the wrong server name. The WSDL
shows the address to be "HPServer" (which is the Windows networking name of
the server) rather than showing the internet domain name of the server.
Here is the snip from the WSDL file (with the actual names replaced by
aliases for this public posting...)...

<wsdl:service name="MyService">
<wsdlort name="MyServiceSoap" binding="tns:MyServiceSoap">
<soap:address location="http://HPServer/action.asmx"/>
</wsdlort>
<wsdlort name="MyServiceSoap12" binding="tns:MyServiceSoap12">
<soap12:address location="http://HPServer/action.asmx"/>
</wsdlort>
</wsdl:service>

Within my client application, after I do "update web reference" in VS2005, I
have to manually replace all occurances of "HPServer" throughout the project
with "domainname.com" to make it work correctly.

How can I fix this, so the Web Service on the server advertises the correct
address?

Thanks,
-- Bruce

Hi Bruce,

Glad to see you again. How are you doing on the former webservice/ ISA
server issue, have you got any progress on that?

Regarding on the ASP.NET autogenerated WSDL document, it will always
generate the service address through the local intranet's address of the
machine(in your case it's the machine/server name of the development
machine). Actually, the public ip address or dns specific address name may
vary depend on the network environment between the client and server, so
it's abit hard to let the ASP.NET webservice dynamic generate the correct
ip/servername address accordign to different client.

IMO, for development time, since we can test the webservice through local
client or local intranet client, the default autogenerated wsdl document
and service description page should be ok. When we need to deploy/publish
the webservice to production server(which has certian public ip address or
dns server address), we can consider customizing the webservice description
page. And currently there're two simple means to do this:

1. Entirely replace the default generated webservice description page with
our custom page and also use our custon wsdl document(may copy the
autogenerated one and modify the service address element value).

2. Just provide a custom WSDL document page(through WebServiceBinding
setting).

Here are two web articles discussing on this:


#<wsdlHelpGenerator> Element
http://msdn2.microsoft.com/en-us/lib...7k(VS.80).aspx

#Using a Custom WSDL File in ASP.NET Web Services
http://pluralsight.com/blogs/craig/a.../15/17482.aspx

Hope this helps and please let me know if there's anything else we can help.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

Steven,

Thanks for your help on this.

Just for clarification, the problem was that the public-facing server (where
the app is deployed) was showing the wrong server name in the WSDL file.
Yesterday, we got some help on our ISA 2004 configuration on the server in
question, and that fixed the problem. The WSDL is fine now.

Thanks,
-- Bruce

"Steven Cheng[MSFT]" <> wrote in message
news:cxT%...
> Hi Bruce,
>
> Glad to see you again. How are you doing on the former webservice/ ISA
> server issue, have you got any progress on that?
>
> Regarding on the ASP.NET autogenerated WSDL document, it will always
> generate the service address through the local intranet's address of the
> machine(in your case it's the machine/server name of the development
> machine). Actually, the public ip address or dns specific address name may
> vary depend on the network environment between the client and server, so
> it's abit hard to let the ASP.NET webservice dynamic generate the correct
> ip/servername address accordign to different client.
>
> IMO, for development time, since we can test the webservice through local
> client or local intranet client, the default autogenerated wsdl document
> and service description page should be ok. When we need to deploy/publish
> the webservice to production server(which has certian public ip address or
> dns server address), we can consider customizing the webservice
> description
> page. And currently there're two simple means to do this:
>
> 1. Entirely replace the default generated webservice description page with
> our custom page and also use our custon wsdl document(may copy the
> autogenerated one and modify the service address element value).
>
> 2. Just provide a custom WSDL document page(through WebServiceBinding
> setting).
>
> Here are two web articles discussing on this:
>
>
> #<wsdlHelpGenerator> Element
> http://msdn2.microsoft.com/en-us/lib...7k(VS.80).aspx
>
> #Using a Custom WSDL File in ASP.NET Web Services
> http://pluralsight.com/blogs/craig/a.../15/17482.aspx
>
> Hope this helps and please let me know if there's anything else we can
> help.
>
> Regards,
>
> Steven Cheng
> Microsoft Online Community Support
>
>
> ==================================================
>
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
>
> ==================================================
>
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>

Thank you for the followup Bruce,

Glad that you've fixed the problem now. Anyway, if you have any further
questions or anything else we can help later, please feel free to post here.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.