- It seems when you deploy a feature containing web parts, you still have to add it to the web part gallery for each site.
- If you want to reference controls in the CONTROLTEMPLATES directory, you can use the virtual path ~/_controltemplates.
- If your controls have a code behind that is strong named, you must fully qualify the Inherits attribute of the @Control directive.
- To remove broken webparts from a page, add the query string ?contents=1 to the URL. (Via http://sharepointinsight.blogspot.com/2008/06/remove-bad-or-broken-web-parts-from.html)
- To disable friendly error messages (and see the yellow screen of death)
- set the CallStack attribute of the SafeMode node to true
- set CustomErrors mode attribute to Off
- set debug attribute of the Compilation node to true
Wednesday, August 19, 2009
Here are some notes from building a SharePoint web part.
Here are some notes from my experience building a SharePoint state machine workflow.
- All fields delcared on the workflow object must be serializable type or marked nonSerializedAny activities before the workflow activated event will not have access to workflow properties
- Remember to remove dll's from the GAC when building, GAC'ed versions will supersede local versions
- Emailing from SharePoint requires the network service account to have local activation permission for "IIS WAMREG Admin Service" (a dcom service): http://www.cleverworkarounds.com/2007/10/25/dcom-fun-with-sharepoint/
- There is a bug in the delay activity, here are some patches: http://blogs.msdn.com/sharepoint/archive/2008/07/15/announcing-availability-of-infrastructure-updates.aspx, http://support.microsoft.com/kb/953630/
- SetSate is not like a return, the rest of the activities in that phase will still execute
- You cannot have more than one list template in a feature
- Set workflow logging level use this command:
- stsadm -o setlogginglevel -category "Workflow Infrastructure" -tracelevel verbose
- To get and set timer settings use this command:
- To allow unsigned powershell scripts to run use this command:
- Set-ExecutionPolicy Unrestricted
- There is no concept of versioning for Visual Studio created SharePoint workflows
- Instead, include the version in the feature path, name, description and workflow name and description
- Change the assembly version, and the version in each of the other places
- Deploy as a new feature
- Make sure the old workflow is marked "No new instances" after you associate the new version (this should be automatic)
- Based on this, it seems like workflows should be in their own features to allow for simpler versioning
- Delay activities were not working correctly
- Worked with MS Premier support for weeks to try and resolve this
- Resetting the SharePoint timer service made the delay activity work correctly
- When they are initialized in the designer, setting the value to something else in the initialize event does not work
- If you bind the timeout property to a dependency field then it can be set in the initialize timeout handler, much like SendEmailActivity properties