0

我刚刚使用 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

但是我已经尝试过讨论上述内容，但它不起作用。我有一种感觉，这里缺少一些非常简单的东西。

更新：过了一会儿我发现这篇文章（更新服务参考不起作用），当我将整个编译的 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 应用程序目录的 bin 文件夹中。
  7. 刷新我的浏览器并在 XSD 中看到所需的更改！

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

如果有人能解释这在世界上是如何工作的，以及正确的方法是什么，我将不胜感激。

解决方案：

因此，经过我所有的麻烦，这就是发生的事情：

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

1 回答 1

0

我遇到了类似的问题，这是由旧版本的主服务程序集位于“bin”文件夹中的新程序集附近引起的。他们走到了一起，因为有一次我重命名了它并开始使用新名称进行部署，但旧名称保留在原处，这给我带来了关于丢失合同的间歇性错误。

于 2015-04-21T09:41:49.270 回答