Solving “The Remote Desktop configuration was not generated by Windows Azure Tools”

For some time I’ve had issues with enabling Remote Desktop connections through the Publish dialog from within Visual Studio 2010, where I’ve gotten the following error message:

This time I really wanted to start using Web Deploy to iterate changes quickly, so I needed to fix this, and it turned out to be relatively simple. Just follow the following two steps:

Step 1 – Remove the RemoteAccess and RemoteForwarder modules from ServiceDefinition.csdef

<Imports>
  <Import moduleName="RemoteAccess" />
  <Import moduleName="RemoteForwarder" />
</Imports>

Step 2 – Remove all RemoteAccess/RemoteForwarder settings and the RemoteAccess certificate from ServiceConfiguration.*.cscfg

<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="false" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="xxx" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="xxx" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000+01:00" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
<Certificates>
<Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="xxx" thumbprintAlgorithm="sha1" />
</Certificates>
</ConfigurationSettings>

Now it should work to enable Remote Desktop (and Web Deploy) through the Publish dialog.

Testing/QA environment in Azure for Facebook application

With ongoing quite extensive modifications of core business rules for Am I Interesting, I need a testing environment where I can deploy my application so that other selected people (my partners in crime) can help test out that everything works the way it should before we release into production.

My initial idea was to do this by deploying to the staging slot of my existing Hosting Service is Azure, but this was not a good solution for me because:

  • I need a predictable URL for this environment. When deploying to the staging slot in Azure, a GUID-looking URL is automatically generated that cannot be changed, and this does not work for me since I have to put this URL in the Facebook application settings.
  • I am using Facebook C# SDK for authentication from my ASP.NET MVC application that reads all Facebook settings, including the application URL, from web.config, which cannot be modified after deployment. And I don’t know the URL before the application is deployed.
  • The staging slot for Azure is really intended for a final smoke test before going into production and should therefore have a production-like physical setup, but for my testing environment I only want/need one Extra Small instance to save cost.

The solution therefore was to create a new Hosted Service and use its production slot, which has a known URL, for my testing environment:

An arguable disadvantage of using a new Hosting Service with a predictable and fixed public URL is that it’s more likely to be hit by users who shouldn’t have access to the testing environment. However, this is not a big issue in my case since the Facebook sandbox mode prevents users, other than those that I have explicitly configured, from getting access to the application.

As any other testing environment, I need storage that’s separated from production, so I have created a new SQL Azure database also setup a new storage account for tables and queues (the “p2piter” account below is the one I use in production):

I have then setup a new Facebook application (in sandbox mode) and pointed that application to the new URL:

To ease deployment, I have added a new Service Configuration with settings specific for the testing environment, like connection strings to Azure Storage and SQL Azure:

Also, I’ve added a new build configuration with a corresponding web.config transformation that contains, among other things, the Facebook application settings that the Facebook C# SDK reads:

When it’s time to deploy, I can now simply choose my new service and build configuration to create the complete deployment package:

Done! 🙂