在重建WCF解决方案后，IIS提供旧的XSD和WSDL文件

Question

我刚刚使用VS2010重建了我的WCF解决方案，并将其上传到装有IIS 7.5的Windows 2008服务器上。出于某种原因，即使在清理临时ASP.NET文件之后，重新启动服务器 - http://www.mysite.com/myservice?xsd=xsd1（以及所有其他XSD文件）也会显示旧模式。

结果我生成的WSDL没用。

我在这里发现了这个讨论：http://social.msdn.microsoft.com/Forums/vstudio/en-US/6a9e48e3-25ec-4859-abe4-2b0a335b23ae/wcf-service-wont-update

但是我已经尝试过上面讨论过的事情了，但它没有用。我觉得这里有一些非常简单的东西。

更新：过了一段时间我找到了这篇文章（Update service reference not working），当我将整个编译好的WCF解决方案移动到一个全新的AppDirectory时，它打破了“无法加载”程序集xxxxx或其依赖项之一。 然后我检查了我的Fusion日志，并在其中一个日志文件中找到了它：

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.

解决方法：所以我不认为这是一个解决方案，但是在

之后

1. 我创建了一个单独的解决方案 - 自托管WCF服务主机
2. 在那里添加了我的所有引用（我的WCF服务库就在其中），
3. 构建自托管解决方案
4. 在服务器上运行自托管的EXE，并在浏览器中运行设计时URL。
5. 能够看到正确生成的WSDL和XSD文件！
6. 将必要的DLL放入我的ASP.NET App Directory的bin文件夹中。
7. 刷新浏览器并在XSD中看到所需的更改！

我的猜测是，当我启动自托管服务并在浏览器中运行它时，新的DLL被存储在我不知道的某个临时ASP.NET目录中。然后IIS使用该目录来执行DLL。

如果有人能够解释这个世界是如何运作的，那么我会很感激。这是正确的做法。

解决方案：

所以我遇到麻烦后，发生的事情就是这样：

• 我使用SVN将文件传输到服务器上。
• 当我在服务器上运行svn up时，我用旧文件解决了冲突。
• 因此App Directory包含旧文件，由于冲突，新文件从未在那里存在。

Answer 1

我遇到了类似的问题，这是由于旧版本的主要服务组件位于＆＃34; bin＆＃34;附近的新版本引起的。夹。他们一起到达那里，因为有一次我将其重新命名，并开始使用新名称进行部署，但是旧版本保留了它的位置，这给了我间歇性错误的合同丢失。