If you encounter the following error message, you can guess that the most probably problem lies on WCF configuration since it mentions something about System.ServiceModel which is actually the class library for WCF. You can definitely troubleshoot the error from WCF point of view. But what if it doesn’t solve the problem no matter what you’ve tried. You are sure that your WCF configuration is exactly correct.
Then, I am telling you another possibility of this error message, which I see it as a bug in Visual Studio or more appropriately maybe VS Tools for Windows Azure. If you face the problem when developing your Windows Azure project with source control such as SourceSafe, Team Foundation Server, or Subversion SVN, you most probably encounter the issue that I am talking about.
If you notice carefully, each time you run your Windows Azure project, Visual Studio actually does something on your web.config file. This can be seen if your web.config file is opened, an dialog will prompt you that your web.config file is modified, do you want to reload it.
MachineKey element is actually used by ASP.NET website to configure algorithms and keys to use for encryption, decryption,and validation of forms-authentication data and view-state data,and for out-of-process session state identification.
As you know that any VM instances hosted on Windows Azure will be load-balanced automatically. Since they are load-balanced, nobody can guarantee the same instance will be responsible on particular request. While we need to ensure that any session / view-state data that are sent to browser could be encrypted / decrypted properly, we need to ensure that the machine key of each instance is consistent. That’s the reason why Visual Studio will modify / add your machine key.
The easy way to go is to check-out your web.config file. Thus, it will give your Visual Studio write access to the web.config, to add / modify the machine key element.
Huh… Would it a better solution? As far as I know, there’s no solution for that at this moment. However, Microsoft has captured this “bug” and I do hope it would be fixed for the upcoming released of Azure SDK.
Update 10 March 2011: To solve this problem, install Windows Azure SDK 1.4