Windows Azure uses 64 bit architecture so all dlls deployed to it must also be 64 bit. This poses significat development problem since 'Visual Studio Development Server'  and IIS Express run in 32 bit process. You can always use complete IIS, but it would be better if there was something more lightweight. It turns out there is. There is a nice project on codeplex called "CassiniDev - Cassini 3.5/4.0 Developers Edition" available here. Its binaries are also 32 bit so be sure to get the source and change Build platform target to either 'Any CPU' or 'x64'

and rebuild solution. After that just replace contents of 'C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0' folder with your new freshly build 64 bit capable dev server

It’s been a month since Azure SKD 1.3 has been released with a lot of new features. Let’s take a look at the ability to user Remote Desktop Connection to your roles first.

In order to enable this feature we must configure our deployments to support it. The easiest way to do so is to right click on cloud service project in visual studio and choose deploys. There you can click on 'Configure Remote Desktop connections'.

Here you can enable RDP connections for all roles and you must set the required security credentials. So let’s create a security certificate first.

Then we set user credentials for our RDP account and set its expiration date.

After that, we export the security certificate so we can upload it to the cloud (you can click on view to open it directly).

We also export private key

And then we upload exported file through the Windows Azure Management portal to our chosen hosted service.

If we take a closer look at what our Visual Studio Wizard did, we can open ServiceDefinition.csdef and ServiceConfiguration.cscfg and see xml additions.

Now we can deploy our solution anyway we like.

Once the deployment is complete and our role is in 'ready' state we can download or open .rdp file through Azure Management portal.

Now we can finally connect to our instance

... and azure looks back at you

NOTE: Changes made to instance will NOT be persisted. This was meant for easier debugging. If you want to take full advantage of IIS configuration you will need to use ‘Full IIS’ feature, which will be covered in my next post.

When you're deploying an ASP.NET website that uses the new Routing feature from MVC, you might run into a problem mapping the routes in Integrated mode. The documentation states that using Integrated mode on IIS7 doesn't entail any extra configuration, but in the odd case it does (throwing Error 404 on routed URLs but not .aspx paths), you can open up your web.config file and modify your <system.webServer> / <modules> tag:

<modules>
...
</modules>

... to something like this:

<modules runAllManagedModulesForAllRequests="true">
...
</modules>

Or, if you're not using modules, just put an empty tag within <system.webServer>:

<modules runAllManagedModulesForAllRequests="true" />

That forces IIS7 to always run all loaded web server modules, including URL Routing (inherited from the 4.0 application pool).