Download them here.

New in the November 2009 SDK (quote from Microsoft Windows Azure team newsletter):

• Windows Azure Service Runtime managed library: The latest version of the Service Hosting Runtime API includes support for enhanced communication between roles and for runtime notification of service configuration changes. Direct communication between role instances enables new application development scenarios, including applications that distribute state across role instances. Service configuration changes include an increase or decrease in the number of request role instances and changes to the values of configuration settings.
• Windows Azure Diagnostics managed library: The new Diagnostics API enables logging using standard .NET APIs. The Diagnostics API provides built-in support for collecting standard logs and diagnostic information, including the Windows Azure logs, IIS 7.0 logs, Failed Request logs, crash dumps, Windows Event logs, performance counters, and custom logs.
• Certificate Management: Enhanced support for SSL certificates in Windows Azure and in the Windows Azure SDK enables the secure automated deployment of certificates to services hosted on Windows Azure.
• Variable-size Virtual Machines : Developers may now specify the size of the virtual machine to which they wish to deploy a role instance, based on the role’s resource requirements. The size of the VM determines the number of CPU cores, the memory capacity, and the local file system size allocated to a running instance.
• External endpoints for worker roles. A worker role may now define any number of external endpoints for HTTP, HTTPS, and TCP, and specify the desired port number for any external endpoint.
• Persistent local resource storage: Developers can now choose to persist data written to a local storage resource at runtime when the role is recycled.
• Windows Azure Storage Client managed library: The Storage Client library provides a .NET API for accessing the Windows Azure storage services.
• Improved Development Storage: Development storage provides a high-fidelity simulation of the Windows Azure storage services in the cloud. Tables can now be created dynamically in the development storage Table service and are no longer required to be generated in advance.
• Updated samples: The samples included with the Windows Azure SDK have been updated to demonstrate new features. The samples now include both C# and Visual Basic versions.

As we can see – a lot of improvements and new features introduced in this release. I will made review of them right after will have time to check (hopefully today later)! In any case, glad that MS improve Azure SDK so quickly!

Update: after installation and first review, I found following:

• It seems like Microsoft finally have “official” Client library for Azure Storage. The name is same like from samples before, i.e. “StorageClient”, but now it is in “Microsoft.WindowsAzure.StorageClient” namespace, not like “Microsoft.Samples.ServiceHosting.StorageClient” that was before! It is also VERY extended and improved, so if you going to use Azure Storage, for sure you need to use this library (and I am also going to use it in my EvejobAzNET project) – it give you access to Blob Service, Queue Service and Table Service! Sure like before, it is possible to use simple .NET Client Library for ADO.NET Data Services (and new library use it inside anyway, just check that it reference System.Data.Services.Client library inside)… But with official Azure Storage Client library a lot of tasks become much more simple! You can found this library (*.dll) in “c:\Program Files\Windows Azure SDK\v1.0\ref\” folder, together with other useful binaries!
• It is possible now to use another “official” library to get programmatic access to most of functionality available before only from Azure Developer Portal (and actually I don’t know why, but for some reasons Portal works and looks not best way! You can google, A LOT of people complain about issues with this!).
• A new Library for Logging and Diagnostic functionality was added to SDK (Microsoft.WindowsAzure.Diagnostics namespace) - feel free to review samples in SDK (zip archives available in root folder of SDK installation, i.e. in C:\Program Files\Windows Azure SDK\v1.0 by default – samples-cs.zip for C# version and samples-vb.zip for VB version)
• A lot of other improvements / features was added that relate mostly to development / production environment (Visual Studio Azure support, new release of Development Fabric etc) – they not change significantly your code / application design, instead of features described above that I highly recommend to review in case if you develop for Azure!

Because I build Evejob multi-platform project with support of Cloud deployment scenarios (currently for Google App Engine and Microsoft Azure) and I am sure that best Web software must be ready to be deployed in Cloud(s), it was very interesting to read latest announcement from Amazon: “… AWS Software Development Kit (SDK) for .NET Now Available… “.

Sure it’s just a beginning for Amazon in development of real .NET SDK, but even with this version we can quickly build .NET applications that tap into AWS Cloud.   Yes,  even before developers have good libraries to build such applications, but now looks like we have first “standard” API from Amazon and this fact is very important!

For example, for Ruby there is no such official SDK (or Ruby gem), and developers can choice from few available gems (right_aws, amazon-ec2 or AWS:S3 to name just few).  The same situation for Java - available a lot of “community” libraries, but no official SDK… (ok, ok, for Java we have at least official AWS Toolkit for Eclipse, but Toolkit it is not SDK!!!).

But why it is important to have official “language specific” SDK?

Well, first of all, now because Amazon have few BIG rivals, like Google App Engine (and we know that Google DO have official SDKs, more so, for both Python and Java!) and Microsoft Azure (sure Microsoft always have SDKs – it a BIG plus for Microsoft!).

Also it is important for developers, so they know that if they take some library and put this library as “base” for communications with a Cloud, they will not need to dial with changes in API in case of library author decide to drop development! It is important to have SDK that will be up to date with company services (Amazon in our case), just because we developers want to be SAFE! Sure it is good if there are a lot of open source libraries that EXTEND SDK some way, but it’s just “add-ons” and can’t replace real official SDK!

So it is really BIG day for Amazon and .NET developers – first official “language specific” SDK, and for .NET!!! What will be answer from Microsoft Azure that is still in “Beta”?

Note: in this post I mean “language specific” SDK, not just common SDK that list API for Web Services  with samples how to use them for example, etc… Because most of they time developers dial with some specific language, it is important for services like AWS to provide language specific SDKs so developers can really quickly and “safely” create applications using such “language specific” SDKs! Hope you understand what I mean

In Windows 7, Go to Control Panel \ All Control Panel Items \ Programs and Features

Press “Turn Windows features on or off” and make sure that you select following features:

• Under Internet Information Services make sure that you select available options (including options in sub nodes), that you going to use. Usually it is everything, except probably ASP (but make sure you select ASP.NET instead), CGI (if you going to use any CGI development, PHP for example, you need to select this feature), Server-Side Includes, FTP Server (if you not need to setup own FTP Server) etc:

• Make sure you select Windows Communication Foundation HTTP Activation and Non-HTTP Activation features (features used for example for Azure or WCF development) – see illustration above

if you have 64 bit version of Microsoft Windows (2008, 7 or 2003) it seems like it’s good idea to setup this version (instead of 32 bit) on both developer machine and production servers if you select .NET platform for your Web application and IIS as your hosting solution.

Here are some reasons why:
1) Serialization works much better on 64 bit OS in processes that hosted by IIS (at least for IIS 6,7,7.5). Means that if you want to serialize huge object (for example DataTable) in 32 bit OS you can get “Out Of memory” exception, while on 64 bit OS this works fine! As probably you know, IIS process on 32 bit OS can be practically maximum about 1200Mb size (while theoretically maximum is 2Gb for 32 bit OS) and for some scenarios this can be a not enough (for example if you going to use in-memory / in-process cache etc)
2) If you develop your system on 64 bit OS, you can be sure that it will work well on both 32 bit and 64 bit OS (at least you can check how it works). Usually problems start coming if you develop and test on 32 bit and than decide to host under 64 bit OS…. So why not to avoid this? Cost of both 32 bit and 64 bit OS usually is the same (at least for MS products), so if you don’t have some specific requirements (for example some of your library does not works under 64 bit machine) it looks like make sense to go with 64 bit!
3) In latest Server OS Windows 2008 R2, Microsoft removes 32 bit support and this version available only as 64 bit OS. That is why it looks like now make sense also to move to 64 bit on developer machine!

So, I found for myself following best software combination available today to develop / host .NET Web Application:

1) Developer Machine: Windows 7 Professional / Ultimate / Enterprise 64 bit with at least 8Gb PC memory (as you probably will want to run some virtual machines, your ReSharper will eat a log of memory in whole solution analyzing mode, Visual studio process can grow to 1Gb itself, Microsoft SQL Server same etc)

2) Hosting Server: Windows 2008 R2 (64 bit) with at least 4Gb memory even if you enable only IIS here (i.e. use server just as Web Server, but not as SQL Server etc), but use huge Sessions objects (not recommended, unless you already have stupid code that do so) or in memory (in process) huge Cache (ASP.NET or for example EntLib Cache etc).

Using such combination you will avoid a lot of problems with “Out of memory” related issues!

P.S. yes, yes, I know – instead of “Out of Memory” issue, you will get a lot of problems to make some soft working well under 64 bit (problems with Paths, dll versions etc). But time that you spend to fix all this setup issues, will save you much more time with Visual Studio (or other soft) crashes or when you go live with your application and get 100 times per day same “out of memory” in your logs! I don’t speak here about performance benefits here (if they exists at all) – it make sense to create special post for this!

P.P.S. sure thing, if you get such “out of memory” exceptions it is problems in your code (or in Microsoft code in some cases, like Visual Studio for example, but anyway it’s your fault! ) and you do something bad… In most cases you can change design and avoid such issues (split huge objects to smaller, don’t store in sessions or cache huge objects graphs, etc). In some cases you simply cannot change anything – it’s by requirements this way or you just have old stupid code that you need quickly to fix! In such cases, moving to 64 bit environment can be good temporary solution that will give you time to improve design / coding discipline! Just be worried – if you don’t change yourself – you will end up with same out of memory exceptions on 64 bit OS (store all 100Gb database as one huge serialized dataset in memory cache for example ha ha… I see something like this before really!)

Based on my experience, I suggest to install .NET developer environment in following order:

1) Microsoft SQL Server 2008 (Express with Tools or Express with Advanced Services minimum, as you probably will want to use at least Management Studio after installation… Sure if you have developer, standard or enterprise versions just install them)

2) Visual Studio 2008

3) Service Packs for Visual Studio and Service Packs for SQL Server (order here i think simply does not make any difference)

If you install SQL Server and Visual Studio in wrong order (i.e. Visual Studio and than SQL Server), you will probably have at least issues with Management Studio 2008 installation (update from Management Studio 2005) together with other ’small’, but time consuming issues…