This had me stumped for a little while today. Whilst trying to host a WCF service in IIS we got this message when we tried to access the .svc file:

The type 'YourType, YourAssembly', provided as the Service attribute value in the ServiceHost directive could not be found.

At first the message seemed to be very specific about not being able to find the type - almost as though it had found the assembly so I changed the YourAssembly to utter nonsense to see if the error changed. Alas no, so it was possible that the assembly couldn't be 'found', let alone the type.

Everything seemed to be in order as far as the assembly was concerned. He was in the bin folder and security was setup appropriately. The type, namespace and assembly were quadruple checked and definitely correct. We even hooked up WinDbg and used the sxe ld YourAssembly command in the hope that we'd see the module attempt to load and fail. But nothing.

So I did what I always do in these situations and reverted to my ol' skool Response.Write-ASP-classic-style debugging techniques. First step was to drop in an aspx page that used the Activator to create the type dynamically. Here's the ASPX page (no .aspx.cs required):

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Runtime.Remoting" %>

<%
ObjectHandle oh = Activator.CreateInstance("YourAssembly", "YourType");
Response.Write(oh.Unwrap().ToString() + " loaded OK");
%>

Just drop this page next to your .svc file and navigate to it in the browser. If it works and you can see the name of your type then you have a different problem to ours. I got an error that looked like this:

Could not load file or assembly 'SomeOtherAssembly' or one of its dependencies. The system cannot find the file specified.

Aha! So we could find the type specified in the Service attribute but we couldn't find some of its dependences. That's better - turns out I was missing an assembly that had to be GAC'd for this to work.