Background

Web references in Visual Studio.Net create a proxy class used to access a web service.  Visual Studio.Net uses the WSDL contract of the web service to create a local class that provides methods that mirror the remote service.  The ASP.Net pages used in the project can then simply create an instance of the given class and call the methods like any other class, while the proxy class manages the necessary infrastructure to invoke the remote web service and return the results.  We will review the two types of web references in Visual Studio.Net and discuss a unique approach to using them which reduces errors and administration time.

Static and Dynamic References

The two types of web references are static and dynamic.  Static web references are "hardcoded" with the URL of the web service used when the reference was added.  Dynamic web references use the original URL of the web service as a default, but allow the developer or administrator to override that URL through config files or code.  The dynamic web reference is often used to facilitate the multiple "levels" of servers found in many organizations (development, stage, and production).  Originally the dynamic reference is setup to a development or stage version of the web service while the ASP.Net site is being developed.  Once the site is moved to production it needs to point to a production version of the web service.  It is possible to use the web.config file to override the mapping between the web reference and the corresponding URL in the <appSettings>, but the web.config is often moved with the web site to production so it would continue to use the original value (or would need to be changed before every move).  Another option is to store this in the machine.config file, which would avoid the need to alter the web.config file for each move.  As the site moved to production it would reference the machine.config file on the server and use the proper production URL.  This works well, but requires changes to the machine.config file on production machines (either manually or programatically).  If this is not done properly or is forgotten, the dynamic reference instead uses its default value, which means that a production web site uses a development or stage version of the web service (not good). 

Better Solution

 Our friendly network administrator Brian, after multiple machine.config changes, recommended a better approach.  He suggested using a specific DNS name to reference the web service, and then using the local "hosts" file on the server to resolve the DNS name to the proper IP address of the target web service machine.  This has several advantages:

• Uses static web reference which slightly increases performance since no lookups of config files must be done
• Only requires an entry for each server that hosts a web service, instead of a key for each web service on the given machine.  If there are 5 web services on a remote machine, the config method would require each to be in the machine.config file since the complete URL is stored.  Using the hosts file, only a single entry is required for that machine.  This saves a great deal of administrative time. 
• It is much less likely to result in production web sites pointing at the wrong machine.  If the DNS name is not added to the hosts file, the web service will fail to connect rather than just default to the original URL (which will most likely go undetected). 

Technique

The following are the steps we used to setup a DNS name to web services that exists on our intranet servers:

• Decide on a DNS name to use for the web reference, such as "ws.mycompany.net".  
• Modify the "hosts" file (%sysroot%\system32\drivers\etc\hosts) on each machine that runs the ASP.Net site, add a line with the IP address of the server that hosts the web service
  10.4.3.35        ws.mycompany.net
• Add a static web reference in Visual Studio.Net that uses the DNS name http://ws.mycompany.net/... and the rest of the path to the .asmx file for the web service

Notes

This technique may not work properly if the web service expects host headers to differentiate web sites on the server.  In this case, the host header is the DNS name chosen on the client end, which probably does not exist at all on the remote server.  In the case where a remote service already provides an Internet DNS name, this technique could be used on a particular machine to override the default IP address and enter the specific IP address of a test or stage server.

Another issue may arise for those that have a winsock proxy/ISA firewall client installed on their machines.  These services typically want to resolve DNS names at the proxy server rather than the desktop computer.  In this case, you will need to change the <defaultProxy> entry in the machine.config file from the original setting to one that specifies your particular web proxy and has a bypass list that includes the DNS name chosen for the web service reference.

Conclusion

This technique has proven very useful for web references on our intranet web servers.  It has avoided a great deal of manual work, and avoided errors due to missing or misconfigured web service keys.  

Send comments or questions to robertb@aspalliance.com.