We chased a fun bug in the afternoon after we deployed our new package to our staging server.
Our customized Content Query Web Parts stops rendering.
But we noticed they were still functioning when we drop into edit mode.
This gave us the hint that our XSL was probably stuffed – but it checked out ok in SharePoint designer*.
Digging through the SharePoint logs, we came across two lines that are incredibly suspicious:
0x17C4 Windows SharePoint Services Web Parts 89a1 Monitorable Error while executing web part: System.Xml.Xsl.XslLoadException: XSLT compile error. An error occurred at (1,482). ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri, ICredentials credentials) at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials) at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn) at Microsoft.SharePoint.WebPartPages.WSSXmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn) at System.Xml.Xsl.Xslt.XsltLoader.CreateReader(Uri uri, XmlResolver xmlResolver) at System.Xml.Xsl.Xslt.XsltLoader.LoadStylesheet(Uri uri, Boolean include...
0x17C4 Windows SharePoint Services General 72ks Medium Cannot get ghost document:
The path to the XSL was familiar, and the problem immediately became apparent. It was the old path, we’ve since re-organized our deployment package, and that old path to the xsl file no longer works.
Drop into Style Library\ and delete all the XSL files that are ghosted.
Deactivate and reactivate the XSL feature so they get re-ghosted.
SharePoint designer must have cached the file at some point, so it was happily showing us a copy of the file while in reality due to our re-organization of the feature it wasn’t actually available anymore.
Re-organizing feature package always has hidden costs…