Our team ran into a problem recently in ASP.NET. We’re using a web service in our web application for data access. The web reference was added to a class library project in our Visual Studio 2005 solution. (We use the WAP – Web Application Project – model) . Simply right clicking on the project name in solution explorer and choose ‘Add web reference’ from the context menu. Everything was working perfectly fine.

The problems started when we tried deploying the application to a test server prior to going live with it. The web service was no longer being referenced properly. We racked our brains for a couple of hours trying to find a solution for this. We had a close look at the class library in which the web service was being referenced and found that the web service path was being saved as a setting in a .config file named app.config. The app.config contained the following XML mark-up:

<configuration xmlns="http://schemas.microsoft.com/.Net Configuration/v2.0">
   <sectiongroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    <section name="ACME.Services.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirepermission="false">
     <setting name="ACME_Services_ACMEWebService_ACMEWebService" serializeas="String">

The web reference URL was being read from this config file. But since it was in a class library, the whole thing was getting complied into a DLL on deployment.

The workaround we found for this was:

1. copy the section handler ( the mark-up inside <sectiongroup>…</sectiongroup> ) into the node in the applications Web.config

2. copy the <applicationsettings>…<applicationsettings> section also into the Web.config.

And Voila! Now since this is part of the web.config, it won’t be compiled any more. On deployment, just change the web service path setting ( inside <value>…<value> ) to the new path. Cool, right? 😉