SharePoint 2010 Sandbox Solutions and Visual Studio 2010 Project Templates

by Christian Fredh 3. januari 2010 19:16

Sandbox Solutions for SharePoint 2010 are great news for SharePoint development. I think we will see a lot of great features without the need of doing farm deployments. But sandboxed solutions do have their limitations and not all project templates or SharePoint Project Items (SPI) are available for sandboxed solutions.

Below are lists of the templates installed with Visual Studio 2010 Beta 2 and the availability for sandboxed solutions.

Project Templates

 

Name Available for sandboxed solutions
Empty SharePoint Project Yes.
Visual Web Part No. Visual Web Part template uses a user control (.ascx file) and must be deployed as a farm solution.
Sequential Workflow No. Programmatic workflows are not available for sandboxed solutions.
State Machine Workflow No. Programmatic workflows are not available for sandboxed solutions.
Business Data Connectivity Model No. BDC models is deployed at farm level and are therefore not available.
Event Receiver Yes.
List Definition Yes.
Content Type Yes.
Module Yes.
Site Definition No. Site definitions is deployed at farm level and are not available.
Import Reusable Workflow No. Programmatic workflows are not available for sandboxed solutions.
Import SharePoint Solution Package Yes, if the items that is imported from the package are supported.

SharePoint Project Items

 

Name Available for sandboxed solutions
Visual Web Part No. Visual Web Part template uses a user control (.ascx file) and are not available for sandboxed solutions.
Web Part Yes.
Sequential Workflow No. Programmatic workflows are not available for sandboxed solutions.
State Machine Workflow No. Programmatic workflows are not available for sandboxed solutions.
Workflow Association Form No. Association forms includes .aspx files and are not available for sandboxed solutions.
Workflow Initiation Form No. Initiation forms includes .aspx files and are not available for sandboxed solutions.
Business Data Connectivity Model No. BDC models is deployed at farm level and are therefore not available.
Application Page No. Application pages includes .aspx files and are not available for sandboxed solutions. Nothing under the Layouts folder can be deployed in sandboxed solutions.
Event Receiver Yes.
Module Yes.
Content Type Yes.
List Definition From Content Type Yes.
List Definition Yes.
List Instance Yes.
Empty Element Yes.
User Control No. User controls includes .ascx files and are not available for sandboxed solutions. Nothing under the ControlTemplates folder can be deployed in sandboxed solutions.

More information about sandboxed solutions:

SPWeb.EnsureUser with elevated privileges

by Christian Fredh 3. januari 2010 00:07

When you work with groups and users and custom code in SharePoint you often use the SPWeb.EnsureUser method that according to MSDN documentation “checks whether the specified login name belongs to a valid user of the Web site, and if the login name does not already exist, adds it to the Web site”. The method returns an SPUser object.

The user who runs this method needs to be a site collection administrator and the user or group to resolve needs to come from an Active Directory source.

An alternative is to use SPWeb.SiteUsers[loginName] that also returns an SPUser object without requiring site collection administrator privileges. The issue you run into with using this property is that if the user haven’t logged in yet, the user will not be found, and that is why you want to use the EnsureUser method. But again, you need elevated privileges for this. EnsureUser actually uses the SiteUsers property for returning the user after adding it if needed.

Created a helper method for this purpose, that you might find helpful if working with users from the SharePoint object model. It is written as an extension method for the SPWeb class. It can easily be converted to a regular static method if not using C# 3.0 for SharePoint 2007 development.

public static class SPWebExtensions
{
    [CLSCompliant(false)]
    public static SPUser EnsureUserElevated(this SPWeb web, string loginName)
    {
        if (web == null)
            throw new ArgumentNullException("web");

        if (string.IsNullOrEmpty(loginName))
            throw new ArgumentException("Login name cannot be null or empty.", "loginName");

        using (SPSite elevatedSite = new SPSite(web.Site.ID, web.Site.SystemAccount.UserToken))
        {
            using (SPWeb elevatedWeb = elevatedSite.OpenWeb(web.ID))
            {
                // Allow unsafe updates required, throws exception without, if not administrator.
                elevatedWeb.AllowUnsafeUpdates = true;
                elevatedWeb.EnsureUser(loginName);
            }
        }

        return web.SiteUsers[loginName];
    }
}

As you can see the SiteUsers property is still used to return the user, to get the correct user context, if you afterwards use SPUser.ParentWeb.CurrentUser for example.

Here is how you would retrieve a user using the method:

string loginName = "SOMEDOMAIN\someLoginName";
SPUser user = SPContext.Current.Web.EnsureUserElevated(loginName);

Tags: , , , ,

.NET | .NET 3.5 | SharePoint | SharePoint 2007

Powered by BlogEngine.NET 1.5.0.7
Theme by Mads Kristensen

About Christian Fredh

Christian Fredh

A twenty six year old solutions architect and developer living in Stockholm, Sweden. I work as a SharePoint consultant at Avega Group with .NET and SharePoint development.

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view. Use the information on this site at your own risk.

Copyright

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.

© Copyright 2009, Christian Fredh.