Logo Home   Downloads   Up to Bluedog Limited
SharePoint Thoughts
A blog centered on Windows® SharePoint® Services
Posted by Maurice Prather
If you have a control (i.e. SyndicationGenerator) that alters the page output to produce a custom stream, you will notice on a v3 system that the cache header information for the response always contains information for the web part page that contains the control and not the values you supplied.
 
This obviously problematic if you need to set the cache header for your application.  Controlling cache values is a common requirement for many applications (as with the SGWP).
 
In v2, you could easily set the cache headers as you would with any other asp.net request. 
this.Page.Response.AppendHeader (SyndicationGenerator.HeaderETag, this.ETagHeader);
this.Page.Response.AppendHeader (SyndicationGenerator.HeaderLastModified, this.LastModifiedHeader);
And that was all you needed to do....
 
In v3, your controls will need to instruct SharePoint to not override your cache settings.  SharePoint basically add the cache and etag values at the very last possible moment in time - unfortunately, this is a tad bit too late for your code as it has already run.
 
To circumvent the override behavior, in v3 you will need to add the following to your code...
// V3: Disable cache headers...
System.Web.HttpContext.Current.Items ["DisableSettingBrowserCacheHeaders"] = "somestringvalue";
The value of the string doesn't matter, SharePoint basically checks to see if the object "DisableSettingBrowserCacheHeaders" exists and if it does, SharePoint will not stamp it's own cache and etag values into the response. 
 
 
-Maurice
 
Posted @ 10:49 AM on Monday, March 31, 2008 | Comments:
Posted by Maurice Prather
It's hard to believe, but SharePoint Conference 2008 is only less than a week away.  The best part is that it is practically right here in my backyard.  I'm just a couple minutes away ... :)
 
If you're interested in meeting up for latte or the likes, drop me a line.  There will be a large number of miscellany gatherings hosted by folks like AC and the likes, too. 
 
See you there!
 
Posted @ 7:09 PM on Monday, February 25, 2008 | Comments:
Posted by Maurice Prather
MOSS' Publishing feature creates a "Pages" document library where all pages are stored and hence managed.
 
By default, the Pages document library does not display the "New Folder" option in new items menu.  This is intended for a good reason.
 
However, users like to change default settings.  :)  One of the things that folks like to do is enable New Folders.  Even if you don't explicity the option, you can still get into trouble via Explorer view, SPD, or web dav.
 
Folders are not supported in the Pages publishing document library.  Although possible to create folders and store pages in those folders, the publishing features will not work properly with pages within folders.
 
This is by design. 
 
I've received more than a few blank stares of doubt when I've mentioned this in the past... it just seems natural to want to use folders in a document library, right?
 
That may be the case, but the fact remains the publishing features weren't designed to work with folders.
 
Luckily, Microsoft released a KB article yesterday (2/13/08) that specifically calls out this limitation.
Good information to know... We now have a KB article where stares can be redirected to... :)
 
Posted @ 10:36 AM on Thursday, February 14, 2008 | Comments:
Posted by Maurice Prather

Over the past six months, I've had the opportunity to work with two clients who are trying to rollout new IAG solutions within their infrastructure.  In both instances, one of the main applications targeted for publication by the IAG servers is SharePoint.

IAG is a cool application with advanced functionality.  It's both a hardware and software solution.  It utilizes firewalls, such as ISA, on top of dedicated devices.  It's a neat concept, but I have one major problem with IAG - they are recommending users publish SharePoint sites in an unsupported fashion.

The problem starts with the fact that IAG has a very advanced url rewriting engine.  As such, the application is able to utilize the rewritten urls to basically obfuscate internal urls.  It's almost analogous to ASP.NET session-based urls. 

For example, if you have a internal url such as ...

https://internal.example.com/someSite/default.aspx  

IAG can rewrite can rewrite the external facing url to become...

https://iag.example.com/iagdt771679732d676564527fcc81aa4dff25adbdf5/iagdt1/someSite/default.aspx 

There are two thing happening at once in this example.  The server name is rewritten and the path is also rewritten/adjusted with a hash value. The hash allows IAG to hide some portion of your internal topology.  IAG goes a step further and allows you to monitor and do a few more things with these "hashed channels".

Now fold in SharePoint into the equation and you bump against a very big issue.  SharePoint does support url rewriting.  Not in v2 and not v3.  However, IAG has continued to advocate their hashed urls schemes as valid scenarios.  If you look at the IAG documentation - whitepapers, slide decks, and videos, dating as far back as v2, url rewriting is encouraged.  This is in obvious conflict with Windows SharePoint Services.

The conflict is interesting from an observer's standpoint because IAG was originally produced/owned by Whale Communications. Whale produced an administrative pack for publishing v2 SharePoint sites, which outlined putting SharePoint into an unsupported configuration.  That's not good, but it's somewhat excusable.  They didn't know better or pay attention to Microsoft's recommendations.  Fast forward to 2006 and Whale/IAG was bought by Microsoft  (a few months before v3 shipped).  Things should get better, right?

In theory since IAG is now part of Microsoft, they should be doing the right thing.  However, as far I know IAG still has documentation and consultants advocating the use of url rewriting for the publication of SharePoint sites.  From a customer's perspective, this a big deal.  On one hand Microsoft is saying "use url rewriting" and the other hand is, and has always been, saying "url rewriting is not supported". 

Who is right?  Windows SharePoint Services.

A product that leverages a platform can't change the platform's stance.  The only team can that modify the stance is the team that builds the platform.  Windows SharePoint Services clearly calls out that url rewriting is unsupported (see section Mistake 2).  More to the point, the SharePoint's documentation throws an even bigger flag for "unsymmetrical" rewrites (see note in Reverse Proxy Publishing section in the technet document previously referenced), which is exactly what IAG has actually told my customers as to how they should publish their SharePoint sites.

It pains me to see 2 customers spend a lot of time and money building and testing solutions with the hashed urls in place.  Why?  It is an unsupported SharePoint configuration.  In my previous position, I dealt with this issue on numerous occasions and helped establish/confirm the url rewriting stance - url rewriting can be very problematic and can lead to weird behaviors and potentially a loss of data.  If a customer is utilizing url rewriting and they run into any problems, they will have to remove the IAG piece before they will be able to escalate any problems to Microsoft support. 

What is the right way to publish "new" urls?  Use WSS' Alternate Access Mapping.  Don't rewrite urls and most certainly don't try to do it asymmetrically.

My request to IAG ... please review your documentation and let your customers know that publishing SharePoint sites with the hashed urls is not a supported scenario.  

NOTE: I realize hashed urls are not the only way to use IAG with SharePoint, but the fact remains that I've now worked with two customers who have closely worked with IAG representatives to arrive at the hashed publication scheme.

Trying to walk the supported line... :)
-Maurice

Posted @ 10:55 PM on Wednesday, February 13, 2008 | Comments:
Posted by Maurice Prather

Guids - love them or hate them?    The simple fact is that you will find them practically everywhere you look.  Especially if you're building a solution on top of SharePoint.

You need guids for Solutions, Features, Content Types, and so forth.  Everyone knows that any SharePoint developer is going to working with Guids day in and day out.

What's the single biggest problem in working with using Guids?  For most folks, they seem like a bunch of random digits and characters.  The randomness makes sense... they is their intended nature. 

Second worst thing about Guids? SharePoint's error reporting system sometimes will give you nothing more than Guid of the offending element.

So... You're left there with some cryptic error message staring you in the face.  Right off the bat, confusion sets in because if you're like me, Guids aren't easy to remember.   Worse yet, if your SharePoint project is fairly large, then the number of Guids that you've come in contact can be quite large.  The entire experience can be frustrating because before you can even start to figure out what may have happened, you need to take time out to go figure out if that Guid is related to something you've specifically created or simply utilized.

It's time to take control of your Guids! 

Over the past year, I've been working with a Guid classification system that tremendously aids both the construction and debugging phases of any development project.  More to the point, when SharePoint throws you a bare bone error message, you can look at the Guid and immediately determine a lot of information from the Guid itself.

Let's first breakdown a Guid so that we can leverage its structure:

  • There are 5 groups of numbers (8 digits, 4, 4, 4, and 12, respectively).
  • The numbers are hexadecimal
  • Guids are by design supposed to be both random and unique

The classification system I'll describe relies on each of these points, with the exception of the last where we will reduce the randomness yet maintain uniqueness.

The advantage of taking control of your Guid structure is …

  • It's super easy to identify Guids as yours no matter where the error appears (on a page, custom app, ULS logs)
  • General structure and dependencies are easy become easier to identify
  • General editing of source data also becomes easier to maintain and track

Starting from the left group, I like to classify each group of numbers within a Guid as listed below and illustrated on the right:

Guid Categorization - System
View full size image
  • Company ID
  • Client ID
  • Project ID
  • SharePoint Category
  • Item categorization

If you aren't too worried about tracking every aspect of your Guids, then the following image presents a partial system. 

Guid Categorization - Partial
View full size image

The partial classification assumes the first 3 groups are left untouched (i.e. you use whatever is spit out by your Guid generator) but you can still take benefit by controlling the last two group of numbers.

For the both SharePoint Category and Item Categorization buckets, the final values use a combination of hex alpha letters (A-F) to identify entities and hex numeric values (0-9) to identify instances of entities.  For example, if your project contains multiple Features, then the SharePoint Categorization group would contain values such as F001, F002, F003, etc.  Note how the "F" represents a "Feature".  You could likewise choose to represent Solutions (D for deployed), Event Receivers (E for event), etc.

The Item Categorization bucket would follow the same paradigm.   For example, Content Type #1 would be represented by "0000000000c1", Field #11 would become "000000000fB", etc.

How does this relate to Content Type IDs?  The classification system makes it easy to create and track Content Type IDs as well. 

Content Type IDs are not nearly as mean and ugly as everyone makes them out.  There are a few key rules when creating Content Type ID...

  • Each Content Type must inherit from another Content Type.  This inheritance is explicitly defined in the ID itself.
  • Each ID length must by divisible by 2 (good info for double-checking anything you've created).
  • Each child is defined by one of two methods...
    • The ID is an extension of the parent plus 2 digits. 
      Example: Document inherits from Item.  Item is 0x01 and Document is Item+01 or 0x0101.
    • The ID is an extension of the parent plus 00+guid
      Example:  System Page Layout inherits from Document thus the ID is 0x01010007FF3E057FA8AB4AA42FCB67B453FFC1.

Best practices dictate that whenever creating a custom Content Type, you should use the 00+ method.  Thus, your old friend the Guid immediately comes into play whenever a direct derivation of an out of box type is made (as illustrated with the System Page Layouts ID).   Once you've stemmed your own branch, you can easily use the 2 digit inheritance model for your IDs as shown below.

As the diagram shows, it's pretty easy to determine the exact tree structure from the content type id "0x0102002A7FFAB099034B25F0040000000000C0c2c1".  You can spot the branch guid (2A7FFAB099034B25F0040000000000C0) and the two descendants (c2, c1).  And, of course, the ancestors (0102). 

Tracking the errors in the ULS logs is made simpler too... it’s pretty easy to determine not only if the error is related to something you created (taken from “2A7FFAB0” signature - aka company signature) but you can rapidly determine

1.  the physical location (feature #4)
2. the problem lies with a content type

At the source management level, I also find the categorization system makes it easier to track and edit items. 

Give it a try... I hope that the categorization system works just well for you as it does for my team.

-Maurice

Posted @ 3:44 PM on Wednesday, November 28, 2007 | Comments:

(Items 1 to 5)Next
Today's hottest posts!
1V3 - How To Publish an ASP.NET Page with Code and Master Page to a Doc Library
Updated: Mon, 12 May 2008 00:39:05 GMT
Keyword Search
 
View by category
MVP Logo
Looking for a team of experts to help with <companyProject type="businessCritical"/>? 
 
My team at ShareSquared can help ... drop us a note.
 
 
ShareSquared, Inc.
 
Subscribe with Bloglines
Microsoft Certified Professional Logo

Disclaimer:
The contents of this site represent thoughts and opinions of the authors , not those of anyone else - such as past, present and future employers.  This a forum of the exchange of ideas centered on SharePoint technologies.  It is not a support channel.  :)

Copyright © 2004-2007 BluedogLimited.com. All rights reserved.