The SPCodeCollection - by Thomas Jorgensen
When adding a SharePoint list item the one field type that has given me most problems is the SPDateTimeField:
First there is the question of entering the date in a format that SharePoint accepts. Then there is the problem of getting the time zone right.Fortunately, neither of the two problems are actually hard to solve – Microsoft has tried to make life easy for us by supplying the tools we need to solve them quietly and efficiently.
When creating solutions for the SharePoint sandbox, whether it is for SharePoint 2010 or Office365, the solution ID must be given whenever some kind of code-behind is used. This is because SharePoint needs to know which assembly to use. Without the solution ID SharePoint would just look in the GAC for the assembly, which would produce a 'File could not be found' exception.
I will show how to supply the solution ID for a number of SharePoint components, and also describe a work-around in a case where we cannot specify a solution ID.
Sometimes we need to make changes to the assembly in a deployed SharePoint 2010 sandboxed solution. Perhaps we need to add something in an event receiver. Or perhaps we added a bug fix (not relevant - the code always works). Or some custom webpart needs to do something else than what it is doing right now.
The only problem is that the solution is deployed in a production environment. We can't just delete and recreate the site, then add the updated solution package, and then tell the users to start all over. So what do we do?
Not to worry: This is a piece of cake - and a small piece at that.
With the increasing popularity of SharePoint 2010, and especially after the introduction of Office365, the market for client applications for SharePoint is increasing. In response, Microsoft has released the SharePoint Client Object Model, which is a wrapper library for the SharePoint web services.
In this post I will demonstrate how you can use the Client Object Model (dare we use the abbreviation COM?) to upload and download files to and from SharePoint. This may prove a central operation if you are migrating an existing SharePoint site to Office365. Other scenarios include uploading an existing file store to document libraries in a local SharePoint farm, or creating plug-in's to existing applications that need to process your documents.
As part of my series on SharePoint auditing, I will demonstrate how to read from the audit log. This is useful if you are restricted to Windows SharePoint Service or SharePoint Foundation, where the out-of-the-box reports are not available, or just need to make your own custom reports.
The auditing is centered around the SPAudit class, which is available in all versions of SharePoint 2007 and SharePoint 2010, except in sandboxed solutions.
As part of my series on SharePoint auditing, I will demonstrate how to write to the audit log. I will also make a few suggestions for what you can use custom auditing for.
The auditing is centered around the SPAudit class, which is available in all versions of SharePoint 2007 and SharePoint 2010, except in sandboxed solutions.
As part of my series on SharePoint auditing, I will demonstrate how to enable auditing programmatically. I will also point out a single dragon lurking in the background.
The auditing is centered around the SPAudit class, which is available in all versions of SharePoint 2007 and SharePoint 2010, except in sandboxed solutions.
In SharePoint 2010 you can access a site using different languages. Recently I had to synchronize list data with an external system, using the list field display names. Since the display name changed with the language, I had to make sure that the external system got the data in a specific language.
After having spent some time activating SharePoint features on a test environment using Powershell, and scratching my head wondering why my code doesn't work, I have come to the following conclusion: Powershell is caching me.
In a recent project I had to create a number of custom list forms. As it turns out, custom list forms are quite easy to create, requiring only an extra attribute in the list schema.xml, a template file, and a custom control to actually render the custom form.
Today, as I was working on a custom list form for SharePoint, I needed to get some information on versioning and content approval for the items in the list. It turned out to be quite straight-forward. Here is what I did.
SharePoint has a small number of built-in permission levels, or role definitions as they are called code-wise. Several of these are easy to access through the SPRoleType enum.
However, the publishing features create new permission levels that are not found in SPRoleType. Although they can be accessed using code such as web.RoleDefinitions["Approve"], this requires hardcoded strings, and is not practical in a localized setting. Luckily, there is a way to access the localization of these permission levels. I got the solution from Alexey Sadomov, and present it here in a slightly modified form.
Creating custom permission levels in SharePoint is not hard. You can do it through the GUI, by navigating to the_layouts/addrole.aspx page on any site.
But you might want to do it through code instead, deploying the new permission level with a feature and assigning it to groups and users. This also includes more options for defining the permission level than the GUI does. Below I show how to define your own permission levels.
Should you want to see what permissions are used for the standard permission levels, then this link is a good place to look.
For my first post on this blog I will demonstrate how to avoid the most common problem with deploying SharePoint lookup fields.
Basically, a lookup field is defined using CAML just like any other SharePoint field. However, there is a problem: You need to add a reference to the lookup list. There are several ways to achieve this. Below, I have outlined three standard ways to do this, and a fourth way, my preferred, that handles the problems inherent in each of the other three solutions.
