title: After rebuilding WCF solution, IIS serves old XSD and WSDL files
body: <p>I just rebuilt my WCF solution using VS2010 and uploaded it onto a Windows 2008 server with IIS 7.5 on it. For some reason, even after cleaning up Temporary ASP.NET files, restarting the server - <a href="http://www.mysite.com/myservice?xsd=xsd1" rel="nofollow noreferrer">http://www.mysite.com/myservice?xsd=xsd1</a> (and all other XSD files) show old schemas.</p>
  
  <p>As a result my generated WSDL is no use.</p>
  
  <p>I've found this discussion here: <a href="http://social.msdn.microsoft.com/Forums/vstudio/en-US/6a9e48e3-25ec-4859-abe4-2b0a335b23ae/wcf-service-wont-update" rel="nofollow noreferrer">http://social.msdn.microsoft.com/Forums/vstudio/en-US/6a9e48e3-25ec-4859-abe4-2b0a335b23ae/wcf-service-wont-update</a></p>
  
  <p>But I've tried discussed above things, and it doesn't work. I have a feeling there's something very simple I'm missing here.</p>
  
  <p><strong>Update:</strong> After a while I found this post (<a href="https://stackoverflow.com/questions/1665976/update-service-reference-not-working">Update service reference not working</a>), and when I moved my whole compiled WCF solution into a completely new AppDirectory, it broke with a "Could not load assembly xxxxx or one of its dependencies.
  Then I checked my Fusion logs, and found this in one of the log files:</p>
  
  <pre><code>LOG: Assembly download was successful. Attempting setup of file:
  C:\inetpub\wwwroot\my\path\to\lib.dll
  LOG: Entering download cache setup phase.
  LOG: Assembly Name is: XXXXXX, Version=1.0.4983.31160, Culture=neutral, PublicKeyToken=null
  ERR: Setup failed with hr = 0x8007000b.
  ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.
  </code></pre>
  
  <p><strong>Workaround:</strong> So I wouldn't consider this a solution, but after</p>
  
  <ol>
  <li>I created a separate solution - self-hosted WCF service host,</li>
  <li>Added all my references in there (my WCF service library was among them),</li>
  <li>Built the self-hosted solution,</li>
  <li>Ran the self-hosted EXE on the server, and ran the Design Time URL in the browser.</li>
  <li>Was able to see correctly generated WSDL and XSD files!</li>
  <li>Threw the necessary DLL's into the bin folder of my ASP.NET App Directory.</li>
  <li>Refreshed my browser and saw the desired changes in the XSD!</li>
  </ol>
  
  <p>My guess is that when I started the self-hosted service, and ran it in the browser, the new DLL's got stored in some temp ASP.NET directory that I'm not aware of. Then IIS used the directory to execute the DLL's.</p>
  
  <p>I would appreciate if someone could explain how in the world this works, and what is the right way to do it.</p>
  
  <p><strong>Solution:</strong></p>
  
  <p>So after all my troubles, here is what happened: </p>
  
  <ul>
  <li>I use SVN for transmitting files onto the server.</li>
  <li>When I ran <code>svn up</code> on the server, there was a conflict that I resolved with the old files.</li>
  <li>Thus App Directory contained the old files, and the new files never made it there, because of the conflict.</li>
  </ul>