Home > Blogs > Eric Shupps | The SharePoint Cowboy > Posts > Tilting at Knowledge Base Windmills
 
 

 Error ‭[10]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 

 Error ‭[9]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 

 Error ‭[4]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 

 Error ‭[7]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
October 27
Tilting at Knowledge Base Windmills
I'm probably going to take some flak for this but sometimes you've just gotta stand up and shout when you see officially sanctioned advice that appears to have come right out of left field.  I'm referring to KB944105 - How to customize application pages in the Layouts folder in SharePoint Server 2007 and in Windows SharePoint Services 3.0.  This is a subject that has long been an Achille's Heel for serious branding efforts so when I saw the title I was hoping to finally get some good guidance on how to handle it.  Instead, I find myself shaking my head and wondering just what to make of what I'm reading.
 
For those of you not familiar with the issue, when you deploy a custom master page in MOSS/WSS v3, the master page is not inherited by the globally-accessible pages in the '_layouts' folder, known collectively as 'Application Pages'.  These pages provide UI elements necessary for the performance of tasks common to every site collection - viewing and creating lists, setting permissions, modifying list settings, adding content types, browsing for users, etc. The reason for this is simple - these pages are used by all site collections and thus cannot be tied to any single site definition style and branding.
 
The problem, of course, is that here in the real world customers want these pages to look like the site they are accessed from and not the default SharePoint chrome.  And it's not a 'want' it's a resounding 'need' - a must have that is non-negotiable.  An understandable request but one for which we have no effective answer because the master page inheritance model is specifically truncated for application pages.  This leaves us with few options - modify each page individually with code to handle multiple master pages or add our own handler mechanism via HTTPModules to do the work for us.
 
Naturally, neither method is supported by Microsoft.  In the first case, we are told never to modify existing files for compatibility, upgrade and supportability purposes.  Okay, I get that.  In the second case, we are told that custom HTTPModules should not be used although I have never received a clear answer as to why this is so.  I can only assume, because people in the know have told me as much, that there is concern over custom code interacting with the existing HTTPModules that MOSS uses (although this is an obvious straw man argument as the same could be said for event handlers, server controls and web parts). 
 
Um, okay, well, that leaves us in a bind then, doesn't it?  Don't mess with the existing code and don't circumvent it either.  So I'm already confused when along comes KB944105 that tells me the recommended method for solving this problem is - are you ready for it? - modify the existing code!  Huh?  Did I just step off a ledge into a parallel dimension or what???
 
First and foremost, the "recommended" solution (make a backup of the existing 12\Template\Layouts directory then customize all the existing pages) is no solution at all.  Have you ever counted how many pages are in that directory?  Well over a hundred.  Touching each one individually would be an exercise in futility.  Putting that small issue aside, the even bigger problem is that the recommended solution is only valid for a single site-collection.  Have two site collections on the same farm with different branding?  Sorry, pal, you're out of luck.  Finally, and this is what really gets me, we have been told all along that this is the WRONG way to modify anything in SharePoint.  And most of us support this methodology because we agree in principle with the idea that changing up what comes in the box is just plain B-A-D.
 
So on to solution number two which, recognizing that solution number one simply won't scale, suggests that we instead change the default virtual directory mappings in IIS and create multiple layout folder instances.  Well, okay, I suppose that solves the one farm/multiple brands issue, but then you end up with numerous copies of the same files to manage (did I mention that there are more than a hundred of them?) AND you violate another principle of SharePoint customization which is to keep your hands off the IIS configuration and manage everything through Central Administration.  To make matters worse, the article actually warns that taking this approach may break existing functionality that relies on a hard-coded path to the layouts folder.  Ignoring the fact that such hard-coded values ought not to exist in the first place, this means we're breaking yet another rule against interfering with OOTB functionality.
 
I don't know about you but my head is starting to hurt from the implications of this article.  First, we're told not to do something (several somethings, actually).  Then we're given advice that had to be vetted by someone on the product team that says no, go ahead and do the things we told you not to do.  And still no mention of the one thing that actually does work in all scenarios without breaking any rules or hosing your server farm - custom HTTPModules. 
 
I swear there must be people in Redmond with stock in Glenfiddich who do these things to me when they notice my whisky consumption has dropped below distellery-sustaining levels.  If anyone can shed the light of common-sense on KB944105 to those of us stumbling about in the dark, you can find me on the back porch crying my way through a bottle of Ancient Reserve...

Comments

Support

I agree that whatever method you use will be a pain in the ...

But can MS word this to be anymore confusing?

"Modifying the files that are installed by SharePoint is not supported." 

and a little later...

"Product support will provide commercially reasonable support for help with modifications."

So they will help you do the mods, but once you are done they say: "sorry I can't help you"?
System Account on 10/29/2007 8:02 PM

Must do better

Eric, I'm with you - the KB article is nonsense! Neither of the suggested approaches have the flexibility of a custom HTTP module. The reference to hardcoded bits of the product which may refer to 'layouts' isn't what I wanted to hear either.

I'll be sure to test thoroughly, but at the moment it's HTTP modules for me I think. I'd like to see MS do some testing and offer some better guidance on this.

Chris.
System Account on 11/6/2007 4:59 AM

Why did they not make it configurable in the UI!

I have been wondering why the option in the site settings - under look and feel -> masterpages -- where you get to specify which "system page" masterpage to use - doesn't handle this. It seems to me like that was what that was intended for

Do you think there would be a way to get the _layouts pages to think of themselves as systems pages?

I think I will go for the http handler technique - although I have not tried it yet
System Account on 1/18/2008 6:55 PM
 

 Error ‭[1]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 
 

 Error ‭[3]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 

 Error ‭[6]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 

 Error ‭[5]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 

 Error ‭[8]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.
 

 Error ‭[11]‬

 
Web Part Error: One of the properties of the Web Part has an incorrect format. Microsoft SharePoint Foundation cannot deserialize the Web Part. Check the format of the properties and try again.

 


BinaryWave Eric Shupps eshupps The SharePoint Cowboy SharePoint monitoring SharePoint monitoring tool SharePoint metrics SharePoint administratrion SharePoint monitoring best practices SharePoint management SharePoint management tool SharePoint operations SharePoint operationsmanagement SharePoint administration SharePoint administration tool SharePoint SLA SharePoint service level agreement SharePoint operational intelligence SharePoint performance SharePoint performance monitoring SharePoint analytics SharePoint real-time SharePoint intelligence SharePoint ITIL SharePoint service operations SharePoint uptime SharePoint alerts SharePoint health SharePoint tools SharePoint metrics SharePoint diagnostics SharePoint SmartTrack SmartTrack Operational Intelligence


Copyright © 2013 BinaryWave, Inc. All rights reserved.
This site is brought to you by BinaryWave in cooperation with Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy. We hope you enjoy the SharePoint-related content on topics such as performance, monitoring, administration, operations, support, business intelligence and more for SharePoint 2010, SharePoint 2013 and Office 365 created by Eric Shupps The SharePoint Cowboy. We also hope you will visit our product pages to learn more about SmartTrack, Operational Analytics for SharePoint, SharePoint monitoring, and SharePoint administration, while also discovering great offers from our partners. Please visit the blog of Eric Alan Shupps, Twitter handle @eshupps, for more information on application development, the SharePoint community, SharePoint performance, and general technology topics. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational support solutions for SharePoint. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. He is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.binarywave.com/blogs/eshupps.