Maurizio's blog 3.0

The default endpoint and default binding provided by WCF 4.0 are obviously great features that can save developing and testing time, but sometimes this conventional configuration don’t help in case you have some trouble with certain setting that doesn’t work.

The setting I mean in this case concern the Windows Authentication over HTTP.

To enable this setting you have only to configure the basic http bindings with a specified security mode, and then, obviously, configure the IIS authentication for the site/virtual directory that host your service to enable Windows Authentication and disable Anonymous access.

If you make this two simple change, you end up with an ASP .Net error page which says this:

“Security settings for this service require Anonymous Authentication, but it is not enabled for the IIS application that hosts this service”,

that is to say that the Windows Authentication isn’t working and the service requires Anonymous Authentication that is not enabled and then here’s the error.

Why although the configuration is it not working? Because you have not specified a binding for your service, and then the default binding comes into play, and the default binding requires Anonymous Authentication, which is not enabled.

The next logical step is to provide a specific binding configuration,  which maps the binding named “BasicHttpEndpointBinding” defined early with your service.

But when you run the service the error is always the same. What’s wrong with this configuration ?

The problem here is the service name you provided. This name must match with the service name written inside the .svc file of your service. If this name doesn’t match, the explicit binding configuration doesn’t match with those provides by your service as well, and then you fall into the default binding behavior again.

Otherwise, if the service name matches everything works fine.

Moral of the story: “Pay always attention to the default values of any configuration”!

If you host a WCF service on a machine with UAC enabled, Vista or Win7 for example, you might run into a seemingly strange exception:

The reason is due to the fact that to host a WCF service you need to register its url, and this task requires administrator privileges, and this means as well that if you run Visual Studio as Administrator everything works fine, but what if you don’t have this possibility ? Or how to register an URL for it to work ?

If you follow the link mentioned in the error message you waste your time because the resulting link is too general for this specific error. I used this approach: I downloaded HttpNamespaceManager, a little and nice open source utility (not an official Microsoft tool), also provided with source code, that just does this, register an URL even assigning permissions to users.

After the URL registration your service will work fine.

Starting from WCF 4.0 it’s possible to use a default endpoint in absence of explicit configuration. This means that you can avoid to configure an explicit endpont because of a default mapping between protocol schema and bindings described in the configuration file machine.config.

Here is the default content of that mapping:

For example, in the case of presence of “http” in the protocol, it will be used the default binding “basicHttpBinding” without the need to configure an endpoint explicitly.

Now, to test this new feature all you need is to create a simple service without an explicit endpoints configuration and then read hits configuration such as the following example:

This code in .Net Framework 4.0 will work fine, while .Net 3.5 would have required the endpoint configuration

Questo workaround spero sia utile a chi si è trovato nella stessa mia situazione, e cioè che improvvisamente Visual Studio 2008 si rifiuta di aggiungere una Service Reference ad un servizio WCF, dando questo errore:

The components required to enumerate web references are not installed on this computer. Please re-install Visual studio.

Ho poi scoperto che il problema si presentava anche aggiungendo semplici web reference (ASP .NET web services) a progetti creati con Visual Studio 2005.

Per risolvere il problema non è mica necessario reinstallare Visual Studio 🙂

Basta lanciare l’ambiente di sviluppo da prompt dei comandi (quello di Visual Studio) con il parametro /resetskippkgs, quindi in questo modo:

devenv /resetskippkgs

Il parametro /resetskippkgs impedisce che siano caricati eventuali VSPackages aggiuntivi, che potrebbero creare problemi con lo startup dei componenti di Visual Studio. Era proprio quello che accadeva a me. Chiaramente basta lanciare solo una volta Visual Studio in quel modo, giusto per disabilitare il caricamento dei VSPackages.