title: How to configure a proxy class for an ASP.NET web service for flexible deployment to production
body: <p>I inherited a web app at the Visual Studio 2003 level that placed all of its code for accessing SQL server in an ASMX web service. This web project had a web reference to the web service. I needed to bring the whole thing under source control, upgrade it to Vstudio 2008 and make a bunch of fixes and enhancements. </p>
  
  <p>In doing this, I came across a <a href="http://www.code-magazine.com/Article.aspx?QuickID=0809101" rel="nofollow">neat article from Code Magazine emphasizing the advantages of "assembly separation"</a>. It was written for WCF but it "inspired me" to:</p>
  
  <ul>
  <li>remove the <strong>web reference</strong> from my main ASP.NET web application project</li>
  <li>add a new project as a class library which I called <strong>ProxyZipeeeService</strong></li>
  <li>add a web reference in the ProxyZipeeeService project to point at the <strong>ZipeeeService</strong> project</li>
  <li>add a <strong>reference</strong> in the main web app project to <strong>ProxyZipeeeService.DLL</strong> produced by building the project of the same name.</li>
  </ul>
  
  <p>The things work and I guess there are some [performance?] advantages to separating things out like this but having described my structure, <em>I need to get to my question/problem</em>:</p>
  
  <p>I run into lots of configuration problems when I deploy this into production that require me to make changes that are quite "awkward" and prone to me screwing things up. Here is my guess about what needs changing but I've searched extensively and cannot understand how:</p>
  
  <p>The ProxyZipeeeService project with the web reference in it produces files as follows:</p>
  
  <ul>
  <li>Reference.map.vb,   ProxyZipeeeService.disco,   ProxyZipeeeService.wsdl   and <strong>app.config</strong></li>
  <li>on my development PC, the <strong>app.config</strong> file produced settings for the URL of localhost (as it should for my PC). Please view this XML entry at: <a href="http://pastebin.com/JtQCxT73" rel="nofollow">http://pastebin.com/JtQCxT73</a></li>
  <li><p>When I publish the web application project to the production web server, the URL for the webservice is "buried" inside the DLL for ProxyZipeeeService (which at this time is in the bin folder of the web app because it is referenced). </p></li>
  <li><p>Because the prod web server is configured to recognize <strong>"host header files"</strong> [another question someday], the URL with localhost fails with a <strong>HTTP 400 Bad Request</strong>. The host header config requires anything related to this default website to use the domain <a href="http://www.zipeee.com/ZipeeeWebService/Zipeee.asmx" rel="nofollow">http://www.zipeee.com/ZipeeeWebService/Zipeee.asmx</a></p></li>
  <li><p>So to fix this, I have been having to "dismantle" my development project for ProxyZipeeeService - completely deleting the web reference, adding it back but this time make the dialog point to the WS on the production server (instead of letting it find the WS in "this solution" because that results in the problematic "localhost" setting). </p></li>
  <li><p>Eventually I am able to push out to the prod server a web project referencing the proxy dll that won't run into this host header issue and it works without throwing the HTTP 400 error.</p></li>
  </ul>
  
  <p><em><strong>But there has to be a better way!</em></strong> </p>
  
  <p>In short, the critical proxy dll cannot be configured with regard to the URL it should use the way I'm set up now. I've tried putting the <strong>applicationSettings</strong> entry from the <strong>app.config</strong> into the <strong>web.config</strong> of my web application project. I've also tried putting a variation on this into the <strong>appSettings</strong> section. Both of these attempts fail.</p>
  
  <p>I hope I have been clear and not been too verbose. Please do not suggest major surgery like WCF because I can't bite off on that now for this project. Thank you for reading and thanks in advance for your help.</p>
  
  <p><strong>EDIT UPDATE: Changing URL in web app's WEB.CONFIG is not detected! Problem remains.</strong> Here is what I did: </p>
  
  <ul>
  <li>Followed exactly what you said to do, lifting the settings from the app.config of the proxy to the web.config of the web app (establishing a new configuration section group that points to my setting from app.config. </li>
  <li>The value in the proxy and now also in web.config reads as: <a href="http://localhost/ZipeeeWebService/Zipeee.asmx" rel="nofollow">http://localhost/ZipeeeWebService/Zipeee.asmx</a> which is fine for testing on my dev PC</li>
  <li>Before deploying all this to the production server, I thought I should test a bit. My first test was with the settings above and I set a breakpoint in the web service project and verified that the proxy had indeed come to localhost as the web.config entry intended and as expected.
  <ul>
  <li>Next (test case 2) I changed the web.config entry from localhost to www.zipeee.com which is where the production webservice the public facing web app uses. </li>
  <li>I left the same breakpoint in the first web service call in place (expecting that it would not be hit because the intention was to use the URL specified in the web.config)</li>
  <li>To my surprise, the breakpoint was hit and when I examined the URL via the Immediate Window, it showed it to be localhost (should have been to www.zipeee.com as desired in web.config). </li>
  </ul></li>
  </ul>
  
  <p>Perhaps I have misunderstood what this approach should allow? Is there something I am missing? I <strong>did NOT rebuild the Proxy</strong> DLL (that remains with localhost) which I thought was the whole intent (i.e. to be able to control the URL in a sort of "late-binding" way via changes to the web.config of the web app). </p>
  
  <p>I remain stumped. Hopefully, you could help me a bit more...Thanks. </p>
  
  <p><strong>EDIT UPDATE: 12 Oct</strong> </p>
  
  <p>Thanks - I read your notes but I'm still confused. The ProxyZipeeeService project code is all generated from the web reference. Here is a snippet from the reference.vb file (<strong><em>are you suggesting I modify this generated code?</em></strong>):</p>
  
  <pre><code>Public Sub New()
          MyBase.New
          Me.Url = Global.ProxyZipeeeService.My.MySettings.Default.ProxyZipeeeService_WSZipeee_Zipeee
          If (Me.IsLocalFileSystemWebService(Me.Url) = true) Then
              Me.UseDefaultCredentials = true
              Me.useDefaultCredentialsSetExplicitly = false
          Else
              Me.useDefaultCredentialsSetExplicitly = true
          End If
      End Sub
  
      Public Shadows Property Url() As String
          Get
              Return MyBase.Url
          End Get
          Set
              If (((Me.IsLocalFileSystemWebService(MyBase.Url) = true)  _
                          AndAlso (Me.useDefaultCredentialsSetExplicitly = false))  _
                          AndAlso (Me.IsLocalFileSystemWebService(value) = false)) Then
                  MyBase.UseDefaultCredentials = false
              End If
              MyBase.Url = value
          End Set
      End Property
  </code></pre>
  
  <p>By the way, could you comment on whether the whole idea of a separate assembly (proxy) for a web service is even a worthwhile thing. There may be some performance benefits (?) but these configuration issues are giving me fits. </p>
  
  <p><strong>EDIT-UPDATE 12 Oct</strong> - a bit later</p>
  
  <p>After the last posting of the code from the generated file reference.vb, I spotted the problem! The declarations you had me place in the web app's web.config file were named:</p>
  
  <pre><code>section name="ProxyZipeeeService.Properties.MySettings"
  </code></pre>
  
  <p>while the reference.vb file refered to the setting as:</p>
  
  <pre><code>Me.Url = Global.ProxyZipeeeService.My.MySettings.Default.ProxyZipeeeService_WSZipeee_Zipeee
  </code></pre>
  
  <p>Changing the web config name to read as section name="ProxyZipeeeService.<strong>My</strong>.MySettings" has enabled the proxy to find the setting in the web app's web.config and I'm now able to "toggle" the web service URL through configuration parameters. </p>
  
  <p>Thank you so much for your help. I am closing this now. </p>
  
  <p>p.s. Do the "professionals" use Proxy classes as wrappers for web services like this? </p>