这个错误本质是WCF运行时无法通过你指定的WcfService1.Service1找到对应的服务类，结合你描述的“之前测试项目正常、现在失效”的情况，我整理了几个核心排查方向：

• 检查服务类的完全限定名是否准确
  打开你的Service1.cs文件，确认命名空间和类名是否和ServiceHost指令里的完全一致：

  namespace WcfService1 // 必须和指令里的WcfService1完全匹配
  {
      public class Service1 : IService1 // 类名必须是Service1，且必须是public修饰
      {
          // ... 服务方法实现
      }
  }
  

  注意C#是大小写敏感的，哪怕是service1和Service1的细微差异都会导致类型找不到。

• 确认程序集名称是否匹配
  很多人会忽略：Service属性的值需要的是**「完全限定类型名（命名空间.类名）, 程序集名称」**。如果你的项目程序集名称不是WcfService1（右键项目→属性→应用程序→程序集名称），那你需要把指令改成：

  <%@ ServiceHost Language="C#" Debug="true" Service="WcfService1.Service1, YourActualAssemblyName" %>
  

  你之前测试项目正常、主项目出问题，大概率是主项目的程序集名称和测试项目不一致，或者测试项目后来修改了程序集名称。

• 清理编译缓存，重建解决方案
  你提到“回到空白测试项目也报错”，这很可能是Visual Studio的编译缓存搞的鬼。试试这几步：

  1. 右键解决方案→清理解决方案
  2. 手动删除所有项目的bin和obj文件夹
  3. 右键解决方案→生成解决方案
     这个操作能彻底清除旧的编译产物，避免缓存的无效程序集干扰。

• 检查配置文件的冲突
  打开项目的web.config（或app.config），重点看两个地方：

  1. <system.serviceModel><services>节点下的<service>的name属性，必须和ServiceHost指令里的Service值完全一致
  2. 如果配置了<serviceHostingEnvironment><serviceActivations>，确认这里的service属性没有和ServiceHost指令冲突，避免重复定义导致的加载异常

• 验证服务类的可访问性
  确保Service1类和它实现的服务契约接口（比如IService1）都是public修饰的——WCF需要通过反射访问服务类，非public类型会被直接忽略。

• 主项目部署时的文件完整性检查
  部署到主项目后，检查主项目的bin目录下是否存在服务项目的WcfService1.dll文件。如果主项目是通过添加服务引用引入的，要确认服务项目被正确引用（右键主项目→引用→确认WcfService1项目在列表中，且“复制本地”选项为True）。

内容的提问来源于stack exchange，提问作者Krst0