In a previous post I wrote about creating a child content type of the BambooFileShareLibrary content type. This was to enable items created in SharePoint via the Bamboo File Share timer job to be set to the custom content type directly and make the additional fields immediately available when users view and edit items.
While following similar steps to make these same fields available when folders were created through the UI, I ran into an unusual problem. The control hierarchy of the page was being written to the output and the text rendered in the browser!
What I Did to Trigger the Problem
To get the functionality I was looking for, I created a new content type based on the Folder (0x0120) content type. I then added the site columns used in the previously mentioned child content type. When the new folder content type was added to the File Share Library, I saw output I wasn’t expecting. I tried the same content type on another document library and it worked as expected.
Where The Problem Lies
I poked around the File Share Library feature and found the Upload.aspx page which renders the unexpected content is contained in the feature. Looking at that I see it inherits from Bamboo.FileShareLibrary.WebpartCreateNewFolder in Bamboo.FileShareLibrary.dll which contains a rather confusing looking OnLoad override when reflected.
I put in a support ticket with Bamboo but I’m still waiting to hear back on a resolution. For now our only approach is to wait or replace the Upload.aspx page with one that doesn’t have debug code in the OnLoad event.
UPDATE #1 (8-Nov-2011 @ 6pm ET):
The Bamboo rep said he’d bring it up in the next meeting in 2 days.
Since that’s not good enough for us I continued to walk through this problem. To start off, I replaced the Upload.aspx in the Bamboo.FileShareLibrary feature deployed on the 12 hive with the Upload.aspx that’s part of the OOB DocLib feature. Lo and behold my problems disappeared. As an unexpected side-effect I also started getting slightly different values in the properties parameter of my ItemAdded event receiver. The minor changes were easy enough to handle.
Since this solved our problem I didn’t bother digging further. I already had a project with our content types packages up into a feature so I added a couple folders under the WSP Builder standard TEMPLATE directory structure to mirror the Bamboo.FileShareLibrary feature. In them I put the Bamboo Upload.aspx file (renamed as a backup) and copied in the DocLib version. Now when our feature is deployed, the Upload.aspx will be overwritten with the DocLib version.
This solution isn’t ideal because any updates to the Bamboo solutions we have could cause the feature to be retracted and redeployed, over-overwriting our change. We’ll have to go back and retract and redeploy our feature to over-over-overwrite the file again. Not too bad really and it gets us over the hump unless and until Bamboo pushes a more permanent fix.
Update #2 (9-Nov-2011 @ 5:50pm ET):
Replacing the Upload.aspx seems to be the cause of new folders created in SharePoint not getting created on the File Share. More work is needed to get the folders created on the file system or wait for Bamboo’s response.
Slayer of 3rd Party Quirks,