Posts
27
Comments
59
Trackbacks
0
October 2009 Entries
Windows Azure Dev Fabric and the PathTooLongException

I’ve been working on converting a complex, distributed, real-world application to the cloud.  It’s been an exciting journey, but also one filled with little gotchas.  One such gotcha was a failure on startup of dev fabric when running a web role containing a series of WCF services.  The specific exception I got ended up being a PathTooLongException.

I dug into the problem and discovered that the folder hierarchy for the ‘deployed’ artifacts running on the local dev fabric is crazy long.  As my project artifacts were deployed, the dev fabric was throwing the PathTooLongException when it ran into an assembly whose full path exceeded the OS limit.  Because of the length of the root dev fabric deployment path, the flexibility of naming your web/worker roles and dependent assemblies is significantly limited.  Here’s what I found:

The root path of deployments made to dev fabric is something like (on Win 2008, anyway):

C:\Users\{username}\AppData\Local\dftmp\s0\

This isn’t crazy (yet), but each deployment consists of a series of hierarchical folders depending on the roles.  Within each role, dependent assemblies are located still deeper within the folder structure.  So, as an example, one of the assemblies might be located at (this was an actual path; names changed to protect the innocent):

C:\Users\{username}\AppData\Local\dftmp\s0\deployment(27)\res\deployment(27).{ServiceDefName}.{RoleName}.0\AspNetTemp\aspNetTemp\root\07ac5e60\bd64b387\assembly\dl3\2cbe1cb5\591b1f0f_1842ca01\{AssemblyName}

This is crazy long!  Without the username, service definition name, role name, and assembly name, I’m already up to 156 characters.  Considering the path length maximums are 248 for the folder name, and 260 for the complete filename, we’re already pretty far along.

Now, consider this:  sometimes, you use 3rd party assemblies, whose names can’t easily be changed.  Take, for example, one of the Enterprise Library assemblies: Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF.dll.  This just happened to be one of the assemblies being used by my WCF services.  Taking that assembly name into account, that’s chewing through another 69 characters, leaving just 23/35 characters total for the username, service definition name, and role name before hitting the directory/path limits, respectively.  That’s not a lot of characters, especially when you consider that some usernames are a concatenation of first and last, such as david.barrett.  Another 13 characters lost.

How do you minimize these tokens?

The ServiceDefName token in the path above can be modified by manually updating the value in the ServiceDefinition.csdef and ServiceConfiguration.cscfg without any effect on the code (in other words, you don’t have to actually change the name of the project or folder:

<ServiceDefinition name="A" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">…

The RoleName is taken from the project name.  This is the same name that shows in Visual Studio, and is not necessarily the name of the project file itself.  I typically name projects (and assemblies) with a ‘namespace’ flavor, such as Company.System.Subsystem/Feature.  In this case, I can’t afford that length, so I had to shorten it something like Svcs after creating the project initially as Company.System.Subsystem.  Blech.

posted @ Friday, October 09, 2009 3:55 PM | Feedback (0)
Call to iPhone Devs for KeePass port

If you’re an iPhone user like me, and you also use KeePass on Windows for password management, you’ve probably noticed the gaping hole in KeePass availability for the iPhone.  There was supposedly a German fellow building a port for the iPhone (http://ikeepass.de/), but after several failures to get the app into the App Store, the project seems to have died.

There are alternative vault apps out there for the iPhone, but I have yet to find a decent one that I like that integrates well with what I already have – KeePass.

I don’t have the facilities to develop an iPhone app (thanks, Apple, for excluding anyone on a Windows platform), but would love to work with someone who has a Mac to manage the work effort.  My plan is to develop a KeePass plugin that syncs the iPhone over WiFi, so I would be happy to do that part.

So, iPhone developers out there – who wants to step up and fill this void?  Feel free to contact me via this forum or leave a comment.

UPDATE (10/7/2009):  iKeePass.de breathes life anew.  A new submission to the app store.  We’ll see what happens.

posted @ Monday, October 05, 2009 12:56 PM | Feedback (2)
News
Comment and opinions are my own and do not reflect on my company in any way.