Skip to main content
Home Forums Silverlight Programming Visual Studio & Silverlight Development Tools Adding service reference using localhost resolves to IP
3 replies. Latest Post by E1Designs on December 12, 2008.
(0)
E1Designs
Member
12 points
54 Posts
12-11-2008 9:34 AM |
The premise is that we have N number of people working on the same project under version control. There for a single service reference is added using http://localhost:9090/somewsdl?wsdl for instance. The idea being that once the 'ip' will always remain as localhost and therefore will work for the developers all workign on the same project. The problem is that when a service point is created on machine X as http://localhost:9090/somewsdl?wsdl it will get resolved in the ServiceRreferences.ClientConfig and then in the configuration.svcinfo, etc... as http://10.1.1.1:9090/somewsdl?wsdl with 10.1.1.1 being the ip. The othe rmachines don't do this. My question is why is this happening on one machine? Is there a setting somewhere? Nothing appears different in the ...system32/drivers/etc/host file...
bartczer...
Contributor
4190 points
734 Posts
12-11-2008 1:30 PM |
In your Web applcation click on Properties. Select the "Web" tab and make sure your settings match across both computers. In this part you can select how you want your local application to start (localhost, port or use IIS). Maybe one of those settings is out of sync...I always change it to use IIS and use a named IIS virtual directory and this allows me to access the build while its running from different machines easier and it make debugging from Fiddler easier as well.
12-11-2008 2:15 PM |
Everything appears to be the same. This is for the web service...not necessarily the web application. So the service resides at http://localhost:9090/somewsdl?wsdl, yet when I updated that reference the generated proxy code where applicable tosses my IP in, versus sticking with localhost as the other machines do.
12-12-2008 10:09 PM |
This was not an issue with Visual Studio/Silverlight. The belief that the WSDL was the same across the board is not valid, there is actually a different WSDL at the endpoints.