I was debugging an issue with a heavily customized SharePoint site where users were unable to save any changes they made to SharePoint list views. Since this was a heavily customized site with several custom list definitions, my initial thought was that we may have botched a list definition or two and made these lists and list views non-modifiable. However, I also tested creating an out of the box SharePoint List and found out that its views were not modifiable as well. In order to isolate the issue, I created a second web application with a simple Team Site site collection. In this web app/site collection, the list views were all modifiable so I knew that the issue was definitely related to something in our particular web application.
The next thing I did was check the ULS logs. In the ULS logs, I noticed the following entries immediately posted after attempting to modify a list view:
The key errors I noticed were the fact that, for some reason, certain resource (.resx) files couldn’t be loaded. These errors were quite strange. First, I wasn’t sure why these resource files were being loaded in the first place. Second, I could not understand why SharePoint was trying to load the files from C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14Resources. These resource files don’t reside there; they are located under the application’s App_GlobalResources directory. But even manually placing the correct resource files in the Resources directory where the application was attempting to load from didn’t resolve the issue.
A little bit of research led me to a post by Ivan Neganov entitled ‘Writing Trace Output to ULS Log in SharePoint 2010’. In the post, Ivan describes a little caveat that enabling ASP.NET tracing caused some SharePoint instability, namely the inability to create a new web part page and the inability to open up a SharePoint site with tracing enabled with SharePoint Designer. Taking that clue, I removed the system.web/tracing element from our application’s web.config and, sure enough, that resolved the issue.
So there seems to be a little laundry of things broken by ASP.NET tracing in SharePoint 2010. Have any of you had any other issues you’ve encountered?