Nov 182008
 

As mentioned in the title, the @Created date field (or site column, depending on your terminology), the date of document creation, which is by default available to all pages and documents, is not replicated when you create a site variation. It is however *linked* to the original document from the original site itself. So if you ever decide to turn off site variation, you’ll lose the @Created date field on your site variation, and there’s absolutely no way to get it back, or at least I haven’t found a way to get it back without hacking it through code.

So be careful when you decide to create a site variation. This “feature” caught us all by surprise, especially when variation was turned off and still wanted the persisted site.

One suggestion to get around it is to create another field and set the computed value to today’s date. I’ll blog more on how we solve this problem when we actually do.

Nov 112008
 

Note to self – Before developing on SharePoint, always enable debugging on the development machine to see a “little” more verbose error messages. Edit the web.config and change the following:

<SafeMode MaxControls="200" CallStack="false" > <!– Becomes –>

<SafeMode MaxControls="200" CallStack="true" >

 

<customErrors mode="On" /> <!– Becomes –>

<customErrors mode="Off" />

 

<compilation batch="false" debug="false"> <!– Becomes –>

<compilation batch="true" debug="true">

Nov 112008
 

Note to self – If using any external assemblies that try to access Microsoft.Sharepoint assemblies, remember to change the trust level to full in the web.config.

<trust level=”Full” originUrl=”" />

This is only used during development.

When it comes to production, install assembly into the GAC with gacutil /i to allow external assemblies access to Microsoft.Sharepoint assemblies.