This blog has moved to http://blogs.msdn.com/b/appfabric please update your links!
Today I am blogging about a common mistake that several developers have committed when using our latest .NET 4 bits. This user experience has its origin in the simplified configuration work developed in this upcoming version of the framework. I will summarize it with the following scenario.
Therefore, a set of default endpoints will be added to your service.
The look of this service configuration probably reminds you of what you previously had to write to develop your web services in .NET 3.5 using WCF.
In order to make sure your service is ready to be deployed, you can press CTRL-F5, and then select Service1.xamlx. The following unexpected screen appears:
Why is the metadata publishing currently disabled? Looking at the configuration file, the service we just opened seems to have a ServiceMetadataBehavior with the httpGetEnabled property set to true. Why is this not working properly then?
If you take a closer look at the configuration file, you may realize the following: the default service name in the WCF Workflow Service Application template is Service1, and not Service. After changing the service name in the configuration file to be Service1, and pressing CTRL-F5 again, you will now be able to see the following:
The correct configuration has been added to your service!
What we have experienced here is the result of mistyping your service configuration name. When the service was opened, since no explicit configuration was found for it, a default set of endpoints with no default service behaviors was added to your service, and that is why the metadata publishing was not being enabled.
In .NET 3.5, the user experience was an InvalidOperationException thrown when a service was to be open to indicate that it “has zero application (non-infrastructure) endpoints. This might be because no configuration file was found for your application, or because no service element matching the service name could be found in the configuration file, or because no endpoints were defined in the service element.” However, due to the simplified service configuration work in .NET 4, this will not be the case in the upcoming version of the framework, and users will need to make sure that the proper configuration (e.g., security, encoding, etc.) is correctly added to their services.
We are currently thinking on different ways to mitigate this. Adding design time configuration validation seems to be the best solution so far. Opinions?
What about providing service registration information from the WCF DLL itself? So you build your WCF-project and implement your services. It makes sense having some bootstrapper logic which would export the implemented services. No magic strings in the web.config, since you can use the typeof(xx).FullName in your bootstrapper/registration process.
This approach also solves our issue with a multi solution environment where multiple solutions provide multiple WCF-projects. Ideally the WCF-projects would be self supporting and it would be enough to place them in the bin-folder of a website project to enable the services.