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.
Recently I started at a new company doing in-house work. The environment is a bit different than that to which I’m accustomed by its large reliance on 3rd party utilities and solutions. While these are great for companies lacking in development staff, many of these solutions are overly generic and can be frustrating to users who are looking for a more integrated experience.
Enter me and my first project.
In my current environment, just as in every other environment I’ve seen, we have users who use and love their file shares. These bastions of untamed digital wilderness have been the bane of many an IT person but their existence continues. To help mitigate some of the drawbacks of these audit-free, backup-less storage areas, Bamboo created a product which synchronizes file share content with a SharePoint document library. The solution uses a timer job to occasionally crawl the share looking for files and folders that have been added/changed and comparing against the files it has in the SharePoint library to see if anything has been deleted. The library is kept in sync (though with the option of archiving deleted items to soften the blow of those occasional accidental share deletes) and each item has a status which reflects the synchronization type.
I was debugging a problem with SharePoint 2007 Site Usage reports on a client farm and I finally figured out the problem.
Out of the box, SharePoint 2007 uses Report Viewer controls to render Site Usage reports. These reports target Report Viewer version 8 assemblies which correspond with the Visual Studio 2005 report designer. In the recent past we deployed some reports which were designed in Visual Studio 2010. To support these reports, the SharePoint web.config was modified to use the Report Viewer version 10 assemblies. This worked to get the new reports to render but a few days later it was discovered the Site Usage reports were no longer working.