I just saw Rocky's article on CSLA 4.2 and Azure.
I have a Clickonce WPF app using CSLA 3.8 (WebServiceProxy) with a SQL Server database. Once of our libraries also uses CSLA 2.0. Does anyone know if it would be worth exploring migrating my middletier and the database to Azure (using SQL Azure).
Your CSLA 3.8 code is running in .NET 3.5?
It is important to understand that .NET 3.5 (and 3.0) are purely additive to .NET 2.0. In other words, any 3.5 code is actually running in .NET 2.0, but with some extra libraries.
I don't know if Azure allows you to run .NET 3.5 code, but I suspect that it supports 3.5 and 4.
Where I'm going with this, is that if Azure requires .NET 4, then you'll need to update your CSLA 3.8 code to run in .NET 4. That's not super hard, but there were some quirky things with WCF and WPF that we had to change as we created CSLA 4.
The bigger question is a business one: why Azure? Do you need the scalability, or the fault tolerance? Or the global reach? Or are you just looking for an external hosting service?
Are you comfortable with Microsoft's SLA terms? Can your app work acceptibly with the (probably increased) latency of having the back-end services run somewhere on the Internet? Do you know your bandwidth requirements and the costs they'll trigger? Do you know your I/O "transaction" volume and the costs that'll trigger?
To my mind, those business questions are the ones that determine whether it is worth exploring moving any middle tier or database to Azure.
Assuming Azure runs .NET 3.5 code, it is trivial to host the data portal in Azure. Certainly it is trivial in .NET 4. It is a little harder (sometimes) to use SQL Azure, because you might be using SQL Server features that don't map directly. If you aren't using "fancy" features of SQL Server though, it is generally pretty easy to move to SQL Azure.
Copyright (c) Marimer LLC