我的WCF服务中出现以下运行时错误。
Could not load file or assembly 'MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
经过一番环顾,我发现了使用Assembly Binding Log Viewer或Process Monitor的建议。两者都没有产生任何信息(也就是说,日志查看器根本没有显示任何信息,并且进程查看器没有看到正在尝试的程序集加载。
我终于遇到了一个建议,即使用this utility (dependency walker)找出程序集实际上正在寻找的内容。开场时,我立刻收到了错误;日志说明如下:
错误:找到了具有不同CPU类型的模块。 警告:找不到至少一个延迟加载依赖项模块。 警告:由于延迟加载相关模块中缺少导出功能,至少有一个模块具有未解析的导入。
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
根据模块列表,它找不到这些:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL
其中一些看起来与RT框架有关;但是,这个应用程序是在.NET 3.5中开发的(实际上,这不是严格意义上的 - 它是在4.5中开发的,并降级为3.5)。
看一些这些文件似乎意味着它们是非常核心的Windows文件,奇怪的是,我已经在解决方案的其他地方使用了这个dll(诚然在客户端上)而没有问题。
我正在使用VS2013虽然我已经尝试过VS2012并且遇到了同样的问题。
我确实遇到this question乍一看似乎是相同的,尽管它与C ++有关。
任何人都可以给我一些指导,说明问题可能是什么,或接下来要尝试什么?
这是我的融合日志:
=== Pre-bind state information ===
LOG: DisplayName = MyAssembly.MyLib.XmlSerializers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, processorArchitecture=MSIL (Fully-specified)
LOG: Appbase = file:///c:/myprog/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = myprog.exe
Calling assembly : System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\myprog\bin\Debug\myprog.exe.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
我设法减少了有问题的库,直到它只是一个返回字符串的静态函数,仍然得到错误。
答案 0 :(得分:3)
总是帮助我解决此错误的事情是仔细查看错误消息的部分“或其中一个依赖项”。
答案 1 :(得分:3)
带有WCF的Visual Studio有一个怪癖 - 如果使用选定的平台构建,它会将程序集转储到特定于平台的文件夹中。如果使用“Any CPU”进行构建,则将其放在WCF的“Bin”文件夹的根目录中。
什么时候配置IIS来帮助你?它会自动假定您的程序集将位于该“Bin”文件夹的根目录中。
网络事件是当您选择“x86”而不是“任何CPU”时,您最终会在错误的位置构建程序集,并且突然您的WCF无法运行。因此,这是少数罕见的情况之一,其中无法加载文件或程序集的全部错误告诉字面意义 - Visual Studio将您的程序集放在错误的位置,现在它无法找到它。 / p>
我不知道为什么他们这样做。 WCF有一些......有趣的设计决策。
答案 2 :(得分:0)
如果您有多个项目,则在Visual Studio中运行应用程序时可能无法构建其中一些项目。右键单击您的解决方案,然后转到属性,配置属性并确认所有项目都设置为编译。
答案 3 :(得分:0)
看起来我不是唯一一个来过这里的人。我会留下它,以防它帮助其他人:
只是忽略错误...它应该如何工作!?
编辑:
我已将此答案取消删除以供将来参考。我终于解决了这个问题。这不是上面的问题,它是我正在使用的解决方案特有的IIS问题。有一个post-build将已编译的WCF二进制文件复制到一个公共位置,但显然不包括新的依赖项。
我将奖励最接近的答案。
答案 4 :(得分:0)
因此,作为WCF服务一部分的库有一个方法,这就是问题方法。
是否可以删除方法及其引用,并且运行时错误是否会消失? 如果您可以将源发布到项目文件中并且您应该考虑从头开始重新创建项目文件,那将会很有帮助。
通过这种方式,如果有任何过时的参考资料被删除,请发布更多有关您的进度的信息......
答案 5 :(得分:0)
我总是发现无法找到总是因为它不在那里。
听起来很明显,但有时候有助于让头脑正确=>有一些东西不存在。
接下来如果你还记得将定义与实现分离的原则,那么暗示你的包含接口和服务的库应该移动到服务的外部dll。现在您已经将代理代码外部化了,如果它本身构建,那么您只剩下实现代码了。作为降级解决方案的一种务实方法是该项目变得“有趣”。
使特定于你的任务的新项目成为一个版本,因为它现在很可能只包含对你的库的引用和一行名为thisismyservicename.svc的文件以及一个地址和绑定它应该很容易复制web.config的system.servicemodel部分。
现在你的原始项目中没有任何东西可以安全地冲洗了。
答案 6 :(得分:0)
在更大版本的visual studio / Asp.Net和运行/部署的计算机上开发项目时,通常会出现此错误。首先检查两台机器的Visual Studio版本。
答案 7 :(得分:0)
我遇到了与wcf相同的问题,我有项目工作,在添加wcf服务后,它停止加载svc文件和相同的问题,没有什么对我有用,最后我删除了服务并重新启动机器,重建一切,最后我再次添加了服务。