For one of my projects, I need to use a WCF service to perform some data manipulations. It is targeting .NET Framework 3.5. It is all good when I try to test the service locally – either in the context of the ASP.NET development server or in the context of IIS7 – no problems at all with the default configuration.
The problem was quite unexpected – when I decided to host my service on my own space (paying for hosting with GoDaddy – Windows Server hosting [IIS7] with .NET support), it didn’t work. What I did is I created a simple folder using a FTP client called svc35 in the server root and copied the code-behind and the service files into that folder. When I tried accessing the service from the web browser, all I’ve got was this error message:
What I did first in this case is check the runtime version – I went to the hosting control panel and noticed that ASP.NET 2.0/3.0/3.5 was selected as the default option. Since I don’t know how the runtime is configured on the server, I switched this option to ASP 4.0 to eliminate the possibility of a framework version conflict (4.0 is backwards compatible anyway).
The problem persists. So what I did is I decided to cleanup the web.config file. By default, it contains lots of optional elements that I don’t need at first stages (after all, I can always add those later).
So what I did is I removed everything but what’s in system.servicemodel. The “clean” configuration file looks as simple as this:
But according to IIS, the problem isn’t yet solved:
This should be an easy fix – I opened web.config once again and simply added the snippet shown above to the main configuration. But there is another important point – as you can see the error is generated in the ‘/’ application – it represents the root node. So another error is expected even with customErrors set to off – the location is not correct and it is obvious that the service simply cannot find its core. To be specific, this is what should be expected:
In the IIS configuration manager (in the GoDaddy hosting control panel), I created a new virtual directory called svc35 (referencing my actual svc35 directory on the server) and set it to be the application root, that way all requests made inside the service will be relative to the application root, instead of the server root.
It will be pending setup for a while – it took around 10 minutes for my virtual directory to become ready.
Once it was ready, I tried opening the service again and encountered another error:
Notice that the application location changed, and now the proper assembly and code elements can be found. The error above is fixed by simply adding a base address prefix filter – basically, the fix is suggested by the error message.
Are we there yet? Not really – there is one more thing that should be handled – HTTP binding. For now, the service throws this error:
There is also an easy fix for this in web.config (add to system.servicemodel):
I found the part of the configuration file that defines my endpoint and set the binding configuration to unsecured (this is a name, not an attribute or mode) – the one I just created above.
I saved the configuration file and uploaded the new version to the server and there it is – a working service:
For now, I’ve noticed that these steps are needed to configure a 3.5 service – when I uploaded a 4.0 WCF service application, it worked right off the bat without additional web.config tuning.
NOTE: Don’t forget that the correct runtime version should be used.