Most recent ASP.NET developers don't know much about the WCF architecture anymore, despite the decent amount popularity achieved by that framework some years ago: the acronym stands for Windows Communication Foundation, a framework devoted to the development of service-oriented web applications launched by Microsoft several years ago - at the time of the. NET Framework 3.0 - replacing the previous approach based on the well-known (and now antidiluvian) ASMX pages - also called ASP.NET Services.
To fully understand the difference between ASMX and WCF you should read this excellent article by Keith Elder who explains very well the key differences among these two systems, highlighting the limitations of the first and well-explaining the potential offered by the latter. An endorsement certainly deserved, but inevitably the son of his time: October 2008.
With no intentions of questioning the validity of Keith's conclusions, we can now say that even WCF became an outdated architecture these days, especially compared to the features offered by the REST approach, which now undeniably owns the Web Services scene: it's no mistery that the WCF framework has been superseeded by Microsoft itself since 2010, with the development of the ASP.NET Web API and then in 2015, with the advent of MVC6 / ASP.NET Core. Despite this, WCF is still the easiest way to implement SOAP-based Web Services, which is still widely used in business in Italy as well as in the rest of the world. For more information on WCF you can also read this interesting MDSN post.
After this long premise, we finally come to the beef of this post! If you came across this article, you may have encountered a rather common problem that afflicts all developers and / or network administrators when installing their first WFC service on a Windows Server 2012 machine with Internet Information Services 8 ( IIS) or higher. When deploying, when launching the Service.svc page, the most classic HTTP error is returned:
404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
As you can easily guess, the reasons behind such error are obviously due to the lack of mapping of the handler needed to interpret this type of call. There are several ways to work around the problem, many of which - described in other sites - require a manual execution of the ServiceModelReg.exe command: these are undoubtedly valid procedures but might also not work - or create additional problems - if our development machine has a particularly complex configuration.
The resolution method I propose below is slightly longer to pull off, but has the advantage of solving the problem more safely and securely.
- Open the Server Manager interface for machine management, usually present in both the Task Bar and the Start menu.
- Go to the Dashboard and select Add Role or Feature to open the Wizard.
- Select the Role-based or Feature-based installation type and the server you want to work on, that is, your local / local server.
- Go to the Features section: Once there, expand the .NET Framework 3.5 Features node and / or the .NET Framework 3.5 Features node, depending on what you have installed: if you have both, you should perform the following step twice (for each one of them).
- Expand the WCF Services section (if available), then select HTTP Activation (see screenshot below).
- Continue until you complete the Wizard, then click Install.
Once the installation is complete, you will be able to run your WCF Service without incurring in that dreadful 404 error ever again.
That's it for now: Happy WCF!
EDIT: If you have never created a WCF Web Service before and you want to try it out, we suggest you to read this guide. If you need to perform a general purpose, manual SOAP request without using the SoapClient class, you can also read this guide.
