I just hit my head on a Cloud – Microsoft Azure and Full Path Limits

A few of us .NET developers in the office have been playing with Azure for the last couple of months.  A few weeks ago I found this series of MSDN online Azure labs, so we started with Windows Azure/Exploring Windows Azure Storage (seemed like a logical starting point).

We encountered a curious error message with one of the exercises, though, and we think it will impact how we set up our environment for a “real” Azure project.  We had followed the directions for lab – configuring the project settings, pasting in blocks of code to initialize the storage container, and so forth – and then we got to the “F5” moment, when we tried to run the app for the first time.  The app compiled fine, but threw this when it tried to run:

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

As the error suggests, some path or file name was too long for it to handle.  We didn’t find anything specific to Azure with regards to this error, but we did find other people installing other software in a deep folder on their machine, and encountering the same message.  The solution – well, ok, the work around – for them was to install the app as close to the drive letter as they could.  Then the full paths to the deepest files would come in under the limit.

I looked at where we had our sample code installed:

C:\Users\mgilbert\_Projects\Experimental\bgsandbox\FacebookAzure\ExploringWindowsAzureStorageVS2010\Source\Ex02-WorkingWithBlobs\begin\VB

Everything up to the “FacebookAzure” folder was my Subversion folder for all of this tinkering we were doing.  The folder for “ExploringWindowsAzureStorageVS2010” was spelled out so I wouldn’t forget where the labs came from.  The rest was structure established by the sample.  The “VB” folder contained the Visual Studio solution file, and below that were subfolders for the two projects in the solution.

Now, that path is just over half of the 260 character limit that the error message mentions.  However, the project compiled just fine.  It was when it went to start up that we ran into problems.  Then we remembered from a previous week’s tinkering that Azure projects get a little carried away when it comes to the execution folder structure.  Here’s one example of what you see under the /bin folder:

C:\Users\mgilbert\_Projects\Experimental\bgsandbox\FacebookAzure\ExploringWindowsAzureStorageVS2010\Source\Ex02-WorkingWithBlobs\begin\VB\RDImageGallery\bin\Debug\RDImageGallery.csx\roles\RDImageGallery_WebRole\approot

Keep in mind – these are just folders.  This doesn’t have any files in it yet.  This path above has rapidly closed the gap to the ceiling of 260, and if the files are named like {guid}.dll, then we’re pretty much there.

Sigh. 

Ok, I’ll move the “VB” folder contents to C:\VB, and see if that works.

It did.  The app started right up.

*facepalm*

<rant>

This is the year 2010.  Why, oh why, are we still dealing with 260-character limits on full paths?  Even more to the point – why does Azure risk hitting those limits with such deep folder structures?

</rant>

We’ll have to watch this once we start deploying Azure apps to our staging server – our typical folder structure there isn’t as deep as what it is on my local box, but without some additional tinkering I don’t know where the cutoff really is.  We may have to create a separate folder for Azure projects.  I’m also curious if this could happen in the real Azure cloud.  I suspect the folder structure would be largely things like C:\jfh8aks\fuh29nc\42j49d – small enough to fit under this limit, but distinct enough to keep 10, 100, 1000 apps in their own little world.