As a frequent user of the .Net stack, this sort of thing is common and very annoying indeed.
I'd guess that it's probably using a temp path which is close to the length of the path limit on Windows and is either not handling it or truncating it. Either that or it's just shoddy code.
You can generally get around windows' 255 absolute character length limits by using UNC paths. We had that problem at my last company, where the system would allow you to write files into a path but not delete them.
There isn't a modern reason for the limit either. NTFS supports longer path names, as does FAT if I remember correctly. Rather irritating.
Never tried the UNC hack. Might have a bash at that.
The actual restriction is in the Win32 subsystem which has both C string and Unicode versions of API calls. Some API is hooked in via the C API which tends to use TCHAR var[MAX_PATH] as the buffers. It's a royal PITA.
The NT Native API and NTFS don't have such small limits (32k comes to mind).
It's a shame really as NT is a beautiful piece of engineering with a shitty Win32 subsystem thrown on the top.
Dang, that's too bad. This could have been a great opportunity for them. A lot of people are going stir crazy because Azure doesn't support .Net 4.5 either yet. I imagine a lot of folks (including myself) quickly checked to see if App Harbor supported it.
I wonder what the root cause is.