Archive for category Development
SharePoint 2010 Claims Based Authentication Resources
Posted by Michal Pisarek in Configuration, Development, Infrastructure, SP2010 on March 26, 2010
This post has moved to my new blog located at: http://www.sharepointanalysthq.com/2010/05/04/sharepoint-2010-claims-based-authentication-resources/
Enjoy!
C#: Setting the Portal Site Connection property
Posted by Michal Pisarek in Development on August 15, 2009
Recently a client asked to that all Site Collections that are created are automatically connected to the main corporate portal using the Portal Site Connection Setting (Site Actions -> Site Settings -> Portal Site Connection)
To do this in code is very simple as shown below which is actually triggered when a Feature gets activated:
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
using (SPSite site = properties.Feature.Parent as SPSite)
{
PortalLog.LogString("Activating feature for: " + site.PortalName + " at URL: " + site.PortalUrl);
site.PortalUrl = "http://corporate.portal.com";
site.PortalName = "Corporate Portal";
}
}
And thats it you can now you can set this in code and maybe do what we did and attach it to various site templates.
SharePoint Branding: Themes vs Style Sheets vs Relative CSS
Posted by Michal Pisarek in Configuration, Development on July 27, 2009
Introduction
In order to apply CSS to a SharePoint site (this includes WSS 3.0) there are a number of options. This article will discuss the pro’s and con’s of each and I am really interested to see what other people might be using, since we often have this discussion at work.
The three basic methods are:
- Creating a SharePoint theme and embedding the CSS that you would like to use in the theme so that it may be selected by users from the Site Settings on each site, see below
- Creating a style sheet (anything with a .css extension) and then specifying it as the Alternate CSS URL in Site Settings->Site Master Page settings,see below:
<link rel="stylesheet" type="text/css" href="/_layouts/styles/mystyle.css"/>
Comparing the Approaches
So which approach should you use, well lets look at the advantages and disadvantages of each.
Creating a Theme
Advantages
- Allows users to easily select the theme in a familiar interface regardless if they are on a site with the Publishing Infrastructure enabled (such as the out of the box Collaboration Portal) or not enabled (such as a team site)
- Can quickly and easily change themes if a user requires.
- Can use the Alternate CSS URL for any quick fixes if need be.
Disadvantages
- Added programming effort of creating a theme,(have to create an XML file and requires an IIS Reset)
- Themes are NOT automatically propagated to sub sites when a new sub site is created. So if I have a Site Collection with a number of sites that already have my theme applied any new site will NOT have that theme automatically applied, a user will have to configure it themselves.
Specifying an Alternate CSS URL
Advantages
- All sub sites created will inherit the Alternate CSS URL, hence they will have the CSS applied automatically. This is in direct contrast to the theme which will have to be configured.
- Users can easily change the .css file through SPD or the front end of SharePoint and see these changes propagated.
Disadvantages
- In sites without the Publishing Infrastructure enabled there is no way through the SharePoint interface to specify an alternate CSS URL so for things such as Team Sites you have to enable the Publishing Infrastructure feature to allow users to do this from the user interface. Of course this creates a lot of overhead and document libraries which you don’t necessarily want.
Relative CSS
Advantages
- In order to change the CSS a user can simply change the CSS on the document library where it is stored.
Disadvantages
- Real pain to have all these references in Master Pages and then in Page Layouts. Could be a real mess when you try to trace the css to see what is going on.
- Cannot easily change the CSS file or add a new CSS file unless you redo every single Master Page or Page Layout that the link resides on…this could be time consuming and undoubtably will lead to errors.
Some tips!
In my mind branding should always be implemented in themes. For starters a user can quickly and easily change the theme if the want to..especially in team sites. By having an alternatve CSS specified you force your team site users, which will far outnumber publishing sites, to place extra overhead simply to specify a CSS file.
So thats my opinion but I am sure that it will differ from people but hopefully this has outlined some of the issues that you could face.
Listing of SharePoint Site Templates
Posted by Michal Pisarek in Development on May 14, 2009
When doing any sort of Feature Stapling you usually want to associate the feature to an out of the box SharePoint site template.
So here is a listing of the out of the box site templates that I find really useful:
GLOBAL#0 = Global template
STS#0 = Team Site
STS#1 = Blank Site
STS#2 = Document Workspace
CMSPUBLISHING#0 = Publishing Site
BLANKINTERNET#0 = Publishing Site
BLANKINTERNET#1 = Press Releases Site
BLANKINTERNET#2 = Publishing Site with Workflow
MPS#0 = Basic Meeting Workspace
MPS#1 = Blank Meeting Workspace
MPS#2 = Decision Meeting Workspace
MPS#3 = Social Meeting Workspace
MPS#4 = Multipage Meeting Workspace
CENTRALADMIN#0 = Central Admin Site
WIKI#0 = Wiki Site
BLOG#0 = Blog
BDR#0 = Document Center
OFFILE#0 = Records Center
OFFILE#1 = Records Center
OSRV#0 = Shared Services Administration Site
SPS#0 = SharePoint Portal Server Site
SPSPERS#0 = SharePoint Portal Server Personal Space
SPSMSITE#0 = Personalization Site
SPSTOC#0 = Contents area Template
SPSTOPIC#0 = Topic area template
SPSNEWS#0 = News Site
SPSNHOME#0 = News Site
SPSSITES#0 = Site Directory
SPSCOMMU#0 = Community area template
SPSREPORTCENTER#0 = Report Center
SPSPORTAL#0 = Collaboration Portal
SRCHCEN#0 = Search Center with Tabs
PROFILES#0 = Profiles
BLANKINTERNETCONTAINER#0 = Publishing Portal
SPSMSITEHOST#0 = My Site Host
SRCHCENTERLITE#0 = Search Center
SRCHCENTERLITE#1 = Search Center
SPSBWEB#0 = SharePoint Portal Server BucketWeb Template
Another great example and a good tutorial is here
Registry Access is not allowed – Logging to the Event Log and SharePoint
Posted by Michal Pisarek in Development on May 1, 2009
Overview
Any custom development that you do should have logging. Log anywhere, somewhere but please make sure that you do it. As a developer you probably think that logging code is a waste of time but try telling that to the poor infrastructure tech who is trying to work out why the entire SharePoint site or collection is down… with no information.
I log to the Event Log, a custom event log at that. We create our own Event Logs based on the functionality that we create and have pretty detailed logs. Frequently we have options for the level of debugging and using the Event Log provides a familiar interface to the users and also you can set retention policies and so forth to make sure that the logs don’t grow out of control. Additionally by not jamming everything in the Application log we keep things a little cleaner.
But alas things do go wrong and this is one example….
Symptom
You are trying to access the registry because you want to write to the application log, or a custom event log (even better).
So testing goes fine locally and then when you deploy you start getting the “Registry Access is not Allowed” error as seen below:
Possible Causes:
This usually occurs when you code is using the Application.EventLog class in someway (maybe writing to it) but the account that is executing the code (the actual user on SharePoint) does not have rights to edit or read the registry.
This is usually because your feature is trying to write to the application event log and the event source has not been created. Also SharePoint is running under the “Local Service” and the local service account does not have rights to edit the registry.
Solutions:
Create the event source manually using regedit.
This is not really preferred but is one option. It does mean however that if the event source is removed for whatever reason then you are hosed.
- Start Regedit
- Go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlogApplication
- Create a new key under application tag. “<Name of the source>”
Add the event source in your code (usually in the FeatureInstalled event of a Feature Receiver)
This is the preferred way since you don’t have to do anything and its all done by code. I put the Event Source in the FeatureInstalled method of a feature, you can also have the code in the FeatureActivated method as well.
public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{
//Create event sources to prevent register permission errors when activating features
EventLog.CreateEventSource("<Source Name>", "Application");
}
Tip: Don’t remove the Event Source because if you do then when reading the Event Log you will get a message telling you that Windows doesnt know where the event is from, just leave it there…
But wait there is more!
So when you test this on your development machine and all is good, the event source has been created so there shouldn’t be an issue. It works for your account and a test account. But then another users complains that they are getting still getting the same error..what is going on…
Registry Access and Privileges
Unfortunately writing and even reading from the Registry required priviliges. Most commonly the developer is a local admin in the box that they develop so running this code below will be fine:
private void writeLog(string message, SPFeatureReceiverProperties properties)
{
if(!System.Diagnostics.EventLog.SourceExists(properties.Feature.Properties[Property_EventSource].Value))
System.Diagnostics.EventLog.CreateEventSource(properties.Feature.Properties[Property_EventSource].Value,
properties.Feature.Properties[Property_LogFile].Value);
System.Diagnostics.EventLog log = new System.Diagnostics.EventLog();
log.Source = properties.Feature.Properties[Property_EventSource].Value;
log.WriteEntry(message, EventLogEntryType.Information);
}
But then once again when you deploy there is an issues. The solution is to wrap all code that accesses the registry, this includes the SourceExists() and CreateEventSource() methods in an Elevated Priviledges block so that the code runs under the Web Application Pool account and not the local user, so the above code code be re-written thus:
private void writeLog(string message, SPFeatureReceiverProperties properties)
{
SPSecurity.RunWithElevatedPrivileges(delegate()
{
if(!System.Diagnostics.EventLog.SourceExists(properties.Feature.Properties[Property_EventSource].Value))
System.Diagnostics.EventLog.CreateEventSource(properties.Feature.Properties[Property_EventSource].Value,
properties.Feature.Properties[Property_LogFile].Value);
System.Diagnostics.EventLog log = new System.Diagnostics.EventLog();
log.Source = properties.Feature.Properties[Property_EventSource].Value;
log.WriteEntry(message, EventLogEntryType.Information);
});
}
Of course you have to make sure that the Application Pool account has access to the registry but once it does then its all good.






