0 comments
.NET 
*Moved to: http://fluentbytes.com/hosting-ria-services-in-azure/
The past few weeks I have done some work on a mobile application that we use for demonstration purposes. This phone application relies on a backend service that we build with RIA services. You might have noticed this based on some of my previous posts regarding using authenticated RIA services from the windows Phone.
Last week I finally managed to get my Developer account approved so I was able to deploy the application on my phone. This was a great experience at first, but after a few seconds I quickly discovered the development environment does not resolve local host references to my laptop web services. Not that I was expecting that, it was just a wakeup call that I needed to find another way to access my RIA services.
What else to do? Well I own an MSDN account and that provides you with an 8 months Small Instance for free, so why not use that one? So that was my reason to push the services to the cloud. With the new full IIS available, it is pretty easy to get RIA services up and running in the cloud. Just configure your account in the development tools, don’t forget to remove the development storage strings and you have your first service in the cloud. Of course I discovered some bugs in the service code, and I needed to investigate what was going wrong. Now here Intellitrace™ is a real live safer. You can just enable Intellitrace™ and get full historical debugging on your services.
Enabling it is very easy, just check the Intellitrace™ option on your deployment dialog and you are done.
There is just one caveat that I hit and that was the fact that Intellitrace™ and RIA services don’t play nicely at first. You need to configure Intellitrace™ to exclude the *System.ServiceModel.DomainServices.* assemblies. This is nicely described in the post here.
After I added this entry, I finally could access my service endpoints to respond with use full info instead of a 500 server error.
Last week I received a tweed on twitter from Steve Carroll, that this bug might have been fixed in SP1. After I tweeted that I was installing SP1 to check if the bug was fixed I already got tweeds back telling me it is not fixed yet.
I have to confirm the bug is not solved yet. What happens when you call your services is that you get the yellow screen of death from ASP.NET and after that you can take the following steps to capture your Intellitrace™ log:
Then you will see the log file being copied local to your development machine:
Next you can open the Intellitrace™ log file and then you will find the following exception in the log:
When you start debugging at that location (Double click the highlighted line), you can see it is coming from System.ServiceModel.DomainServices.Server and in my case is caused by a call to GetQueryEntityReturnType().
To get rid of this issue, you can configure Intellitrace™ to exclude these modules and then you can start debugging again.
*** Update ****
The bug is fixed! It is fixed in the Service Pack 1 for Visual Studio 2010. I at first tried only the RIA services SP1, but that did not resolve the issue. I was not aware of the fact that the packaging of the cloud application also includes the packaging of your locally installed Intellitrace™ diagnostics tools. If you look at the deployment package, you can find that there is a Plugins folder that contains the Intellitrace™ as a plugin that is registered to start when the role instance is started. Therefore you need the Service Pack of Visual Studio in stead of only the RIA services SP1 to get the issue solved.
*** End Update ***
One other thing to note with Intellitrace™ is that it is using your storage account to dump the log files. At first I thought this was not such a big issue, but after I took a look at my monthly bill, I discovered my transactions allowed in my MSDN account where used for more than half already! I left Intellitrace™ on for a week since I forgot to turn it off. This caused constant dumping of the data to storage, resulting in a nice 53,536200 Storage transactions used from my 100,000000 free transactions. Intellitrace™ enabling also causes azure to refrain from restarting your instance when it is failing. This is done to enable Intellitrace™ to dump the data, but is not a state you want your production environment to end up in.
So to conclude this post, RIA services and Azure work great together, Intellitrace™ is a great tool to debug your application, but be aware of a bug that causes your services to crash when you have Intellitrace™ enabled. This issue is not yet fixed in the Sp1 Beta of RIA services, but I still hope it will be in the final version of the SP.
Cheers,
Marcel
Follow my new blog on http://fluentbytes.com