WCF IIS hosting issue

Question

I am using VSTS2008 + C# + .Net 3.5 to develop a WCF service hosted in IIS 7.0/6.0. I am learning from the following MSDN link,

http://msdn.microsoft.com/en-us/library/ms733766.aspx

My question is, suppose I implement the WCF service inside a class library and compiled into some specific DLL assembly. In the service svc file, seems there is no way to specify the assembly, in the MSDN sample, only full (including namespace) class name is specified. So, how did WCF runtime finds the assembly which contains the actual implementation of the DLL assembly at server side? Even if I put the assembly into bin sub-folder of the virtual directory, and if there are many DLLs in bin sub-directory, how did WCF runtime knows which dll contains the actual implementation for the specific WCF service?

Answer 1

Marc is correct about putting the assembly name after the namespace with a comma to separate it: I can confirm that it worked for my own WCF service when I did that. The "dll" extension was not required.

So it sounds like your error 404.3 is due to something other than that. I'm sure I've had that one before, though I'm unable to reproduce it when I try to now. But I have a feeling it had something to do with the permissions on the folder in IIS - perhaps check to see if opening up the permissions more will fix the problem. I think the relevant users would be the IIS_IUSRS on your own machine, and maybe also other processes like NETWORK SERVICE (though I could be wrong on this).

The other thing that springs to mind is encryption; I found that when my web folders were encrypted (with the standard Vista encryption) they couldn't be accessed properly by IIS and would give errors like this. So if you have encryption on those files/folders, maybe try turning it off.

Answer 2

( not working - I've left this here simply for visibility so other SO users can see what didn't work)

I'd need to check, but I'm fairly certain it follows the usual pattern - so you could also have written "Some.Namespace.Service, Some.Assembly.dll" (or if that fails, try it omitting the .dll from the end).

I seem to recall that there is one minor change to normal here... usually the runtime will respect [assembly:TypeForwardedTo(...)] , but I don't think that WCF handles this - but otherwise, standard type/dll strings should work.