For the project I’m currently working on there’s a requirement to automatically approve items added to and updated in certain lists if the user adding or updating the item has permissions to approve the item. This prevents a user with such permissions having to perform additional steps (in different screens) to approve an item after adding or updating an item.

So, to make things easier and to provide this functionality I’ve implemented a SPItemEventReceiver which could be added to any list or library where this functionality is required. The event receiver code looks something like this:

In this case I’m using ItemUpdated to  set the approval status. Note that in Libraries, an EventReceiver like this should probably better be attached to the ItemCheckedIn event instead…

The Code Snippet below shows the code that will ultimately return the entire collection of ListItems that related to the SPListItem the method is called on:

SPContentType itemContentType = myCustomList.ContentTypes[SPBuiltInContentTypeId.Item];

The SPBuiltinContentTypeId Class contains static readonly fields representing all out-of-the-box ContentTypes in SharePoint Foundation (or WSS). The thing here is that when a Content Type is assigned to a List by using “Add from existing site content types” there actually is a new ContentType being generated under the hood. This newly generated ContentType actually inherits from the ContentType you selected to assign so it (initially) behaves exactly the same as it’s parent but it will have it’s own unique ID.

The SPBuiltInContentTypeId Class’ fields represent only the SPContentTypeIds of the ContentTypes typically instantiated at SiteCollection scope. Referencing a List-assigned version of the “same” ContentType won’t work using the overload of SPContentTypeCollection’s (SPList.ContentTypes) indexer taking a SPBuiltInContentTypeId because the ContentType has it’s own unique ID. In order to reference the List-scoped ContentType you should use one of the other two overloads of this class’ indexer instead. The first is taking an Int32 representing the index of a ContentType whithin the collection. However, for a more predictable result I’d recommend using the overload accepting a string representing a ContentType’s name:

SPContentType itemContentType = myCustomList.ContentTypes["Item"];

So by default, when the Sandboxed Code Service is started, each SiteCollection whithin each WebApplication in your Farm is enabled to execute code in Sandboxed Solutions. Sometimes however you might want to disable the execution of code in Sandboxed Solutions on specific sitecollections while still allowing them to execute on other SiteCollections. There is no neat way to disable code execution from Sandboxed Solutions entirely on a specific SiteCollections. Maybe you’d expect to find a checkbox labeled “Disable Code Execution in Sandboxed Solutions”  somewhere under Site Collection Settings  in Central Admin but there isn’t.

This requirement could be achieved however by specifying a Quota Template and configure a specific SiteCollection to use it. Follow the steps below to specifiy a Quota Template effectively disabling Sandboxed code execution on a certain SiteCollection.

1. Open Central Administration

2. Browse to Application Management

3. Under Site Collections click “Specify Quota Templates”

4. Specify “Create a new quota template” and specify a name for it. Optionally you could start from an existing template here.

5. At the bottom of this page there’s a section with options to control Sandboxed Solutions called “Sandboxed Solutions With Code Limits”. Specify “0″ points in the TextBox labeled “Limit maximum usage per day to”

6. Click OK to save this template

7. Back on the Application Management Page, click “Configure Quotas and Locks”

8. On this Page, select the SiteCollection to apply the new quota template to

9. Under “Site Quota Information”, select the template just created

10. Click OK to save changes

Note that this will only block execution of custom code from within the Sandbox entirely. You are still able to provision declarative elements like List Instances for example to the Sandbox and use them without being blocked. I don’t think this is a problem however because otherwise the Site Collection administrator would have been able to create these kind of elements from within the browser or SharePoint designer anyway.

• The browser is too old: IE 5.01 with SP2 is required
• The “Microsoft Office Access Web Datasheet Component” is not installed. This is included in Office 2007 and also available on the Office 2003 installation disc

Since the Solution Gallery is just a specialized Document Library in which .wsp Files get placed, I thought using the Module element would help me here. Off course, you could use the Module element inside as a Feature element too, instead of the SiteDefintion I’m using it in. So, first of all I declared my Module element as follows:

<Module Name="Solutions" Path="Solutions" Url="_catalogs/solutions">
    <File Url="HelloSandbox.wsp"/>
</Module>

After creating a new SiteCollection based on the SiteDefinition containing this Module, I navigated to the solution gallery to find my .wsp file there in order to Activate the solution but it wasn’t there. It took me a while to figure out that in order to actually find the .wsp here, I needed to specify the Type within the <File>element with the value “GhostableInLibrary”.

<Module Name="Solutions" Path="Solutions" Url="_catalogs/solutions">
    <File Url="HelloSandbox.wsp" Type="GhostableInLibrary"/>
</Module>

Changing this made the .wsp appear but I wasn’t able to Activate the solution. I was wondering why until I chose to edit the properties of the .wsp and Save the changes without changing anything. After this, I was actually able to activate the solution!

So, editing the properties apparently caused some properties to be set under the hood. In order to figure out which properties, I decided to fire up SharePoint Manager 2010. This is a great tool to get useful insights. It helped me to figure out the following properties were added after editing the .wsp properties:

• ContentType
• ContentTypeId
• SolutionHasAssemblies
• SolutionHash
• SolutionId

I decided to (as far as possible) specify the properties listed above one at a time in <Property> elements within the <File> element within the <Module>. By adding them one at a time I was hoping to find the minimum set of properties needed to be set.

I tried the ContentType property first. The value for ContentType (as I could see in SPM2010) was set to “Solution Gallery” so I declared the following <Property> element:

<Property Name="ContentType" Value="Solution Gallery"/>

I then created a new SiteCollection and now I was able to activate the solution! So this one property did the trick! Switching back to SPM2010 showed me that the other 4 properties from the listing above were also set now…

Hope this helps you too!

The Delegate Control is declared with ControlID value “ProfileRedirection” and Scope “Farm”. This means the Feature with the Control element to insert a custom Control also needs to be Farm scoped. Thus, activating this Feature will result in replacing the redirect behaviour through the entire Farm. In our case, this was not a problem but be sure to keep this in mind.

The Feature’s Control Element declaration looks something like this:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Control ControlAssembly="Customer.Intranet, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fe3fb3dd06bf9154"
           ControlClass="Customer.Intranet.ProfileRedirectControl"
           Id="ProfileRedirection"
           Sequence="1"/>
</Elements>

When I launched Visual Studio for the first time to create  a simple Sandboxed WebPart and pressed <F5> to start debugging, I received an error stating that the SPUserCodeV4 service was not running:

The error above was a quite obvious one and easy to fix by just starting this service from the “Services on Server” screen in Central Administrion:

So, I thought I was ready to press <F5> again but now another error appeared stating that Visual Studio was unable to attach to the SPUCWorkerProcess. My first thought was that this was probably some beta issue or an issue caused by not running Visual Studio as an administrator or something like that. My Solution was deployed to the solution gallery anyway so I planned to contiue placing my webpart on the page and attaching the debugger manually if needed. Placing the WebPart on the page however resulted in well ehh…nothing.

In order to confirm I was not doing anything not allowed in my code I changed the WebPart’s functionality to do nothing more then the  classical “Hello, World!”. That didn’t work either which meant I had to dig deeper. After binging around for a while, I found a blogpost by Jie Li in which he describes a PowerShell script to be run on computers that were setup as a domain controller (like mine). After running the PowerShell script below, everything worked fine!

$acl = Get-Acl HKLM:\System\CurrentControlSet\Control\ComputerName
$person = [System.Security.Principal.NTAccount]"Users"
$access = [System.Security.AccessControl.RegistryRights]::FullControl
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]::None
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person, $access, $inheritance, $propagation, $type)
$acl.AddAccessRule($rule)
Set-Acl HKLM:\System\CurrentControlSet\Control\ComputerName $acl

The most basic code I could think of for retrieving this value was the following

SPSecurity.RunWithElevatedPrivileges(delegate() {
  PublishingPage currentPage = PublishingPage.GetPublishingPage(SPContext.Current.ListItem);
  string pageLayoutName = currentPage.Layout.Name;
});


Running this code using Windows authentication works fine. Running this code in anonymous context however caused a challenge to appear when executing the line where pageLayoutName is assigned a value. The reason for this is that some objects referenced in the SPContext object were already created outside of the elevated context. So, to retrieve the name of the current PageLayout, I had to instantiate most of the objects needed to get to the PageLayout object manually. The following code worked for me:

SPSecurity.RunWithElevatedPrivileges(delegate() {
  using (SPSite siteCollection = new SPSite(SPContext.Current.Web.Site.Url))
  {
    using (SPWeb web = siteCollection.OpenWeb())
    {
      PublishingWeb publishingWeb = PublishingWeb.GetPublishingWeb(web);
      SPListItem pageListItem = ublishingWeb.PagesList.ItemsSPContext.Current.File.UniqueId];
      PublishingPage currentPage = PublishingPage.GetPublishingPage(pageListItem);
      PageLayout currentPageLayout = currentPage.Layout;
      currentPageLayoutName = currentPageLayout.Name;
    }
  }
});

The example above is obviously a very specific case in which we needed the name of the PageLayout used by the current Page. The key message here however is to watch out using SPContext (and other high-level SharePoint objects) within an RunWithElevatedPrivileges block while in anonymous context. It’s very likely to run into some differences compared to using the same elevated code in Windows authenication context.

In SharePoint 2010′s object model the SPListCollection Class has a new method called “TryGetList”. This method does exactly what the name suspects. Within the SPListCollection is being searched to a SPList with the specified name. If the list does not exist, a null reference is returned

SPSite currentSite = SPContext.Current.Site;
SPList mySPList = currentSite.RootWeb.Lists.TryGetList("VoorbeeldLijst");

if (mySPList != null)
{
  ...
  ...
}


http://bit.ly/ZI2010

The code in the fragment below is executed in the SendEmail method and explains why:

email = messageHeaders["from"];

if (email == null){  email = web.CurrentUser.Email;}else{  email = FoldEmailHeader(email, "from", true);  count--;}

The code listed above is being executed in the SendEmail method (obtained by using Reflector). As you can see, if the “from” address is not in the StringDictionary “messageHeaders”, the from address is being retrieved from web.CurrentUser. Since anonymous access is being used, this will obviously fail.

In the project we’re currently working on, we have a masterpage with a JavaScript powered menu. In this masterpage, a JavaScript function with the name HideUnhide was defined to toggle the visibility of parts of the menu. 

Page.Response.ClearContent();Page.Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache);Page.Response.ContentType = "application/pdf";Page.Response.AddHeader("Content-Disposition", "attachment; filename=document.pdf");Page.Response.Buffer = true;Page.Response.BinaryWrite(file);Page.Response.End();

Now, when a user clicks the download button, a File Dowload Dialog is displayed in the browser. When this dialog is closed the page is not responding to any click within the webpart’s content that normally would cause a postback to occur. With a little Googling, I found this thread which fully describes the cause of the problem and provides a neat solution.