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!

1. 1) libtiff

Installation of Python Image Library (PIL)

It will be a problems with PIL installation on  Windows 7 64 bit, so you will need to install library from source code:

1. Download PIL library source code from http://www.pythonware.com/products/pil/
2. Unpack it to any  folder, for example C:\PIL
3. Run in command prompt (cmd):

   cd c:\PIL
   python setup.py install

   This will install library, but without support for TKINTER, JPEG, ZLIB (PNG/ZIP) and FREETYPE2 (i.e. actually without anything )

So let’s add support for at least JPEG and PNG. To do this, you will need to download following libraries:

1. libtiff – download sources (zip) from http://gnuwin32.sourceforge.net/packages/tiff.htm
2. zlib – download sources (zip) from http://gnuwin32.sourceforge.net/packages/zlib.htm
3. libjpg – download sources (zip) from http://gnuwin32.sourceforge.net/packages/jpeg.htm

Following blog posts will help you to continue with installation:

• http://www.wiredfool.com/2005/10/29/how-to-build-the-python-imaging-library-for-windows (in case if you want to use Visual Studio to build libraries)
• http://boodebr.org/main/python/build-windows-extensions (in case if you going to use open source software like MinGW or Cygwin to build libraries)

Notes:

1. Possible that you will need to remove

    include <unistd.h>

   from some *.h source files as this needed to be included only on Unix (ok, at least not on Windows)
   For example you will need to delete such line from zconf.h in zlib sources before try to run nmake for zlib.

2. Don’t forget to set PIL library pointers (in setup.py of PIL) to point to the locations where you put zlib, libjpg and libtiff. If you forget to setup  - PIL will not found them and you will get what I describe in the beging of post – I.e. nothing .
   This is for example what you need to set for zlib in setup.py of PIL in case if you copy zlib sources to c:\PIL\zlib folder (I assume that you unzip PIL into c:\PIL here):

   ZLIB_ROOT = './zlib'

3. You also can found yourself with finding all the 32-bit times “__time32_t” and changing it to “time_t” for 64-bit conversion

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!)