Archives

Archives / 2010 / March
  • SharePoint 2010 Developer Dashboard configuration feature

    Tags: Downloads, SharePoint 2010

    The Developer Dashboard in SharePoint 2010 can be configured using STSADM commands, PowerShell or some coding. To easy turn the Developer Dashboard on and off I have created a Farm scoped feature that allows you to configure the Developer Dashboard from Central Administration > General Application Settings > Development Settings.

    Developer Dashboard configuration in Central Administration

    The Developer Dashboard contains more configuration options than just to turn it on or off. With this feature you can configure all of the options available for the dashboard:

    • Display mode (On, Off, On Demand)
    • Auto Launch of Developer Dashboard when critical events is tracked
    • Enable the ASP.NET tracing output
    • Configure the maximum amount of SQL queries traced
    • Configure the maximum amount of critical events traced
    • The required permission to view the Developer Dashboard (Full, None or Custom)

    Configuration of the Developer Dashboard

    If you think this is something you need, and of course you do then you can download the feature here. Extract the ZIP file and install the WSP into your SharePoint 2010 farm!

  • Working with SharePoint 2010 Correlation ID in PowerShell and code

    Tags: SharePoint 2010, SharePoint 2010 Web Parts in Action

    SharePoint 2010 the logging has been extended with a new Correlation ID which is unique for each request or operation. The Correlation ID makes it very easy to track down any unexpected errors since you can search for the id in the trace logs. This unique ID is also maintained between servers for instance when making a call to a service application.

    SharePoint 2010 error message The SharePoint 2010 error page also shows this Correlation ID so that any end-users seeing the message can contact support and give the the Correlation ID. Using the ID the support team can then track down the cause of the error.

    To Search for the Correlation ID in the Trace Logs the Windows Suisse Knife called Notepad can be used but a far better, faster and more 2010:ish approach is to use the Get-SPLogEvent cmdlet.

    Get-SPLogEvent

    The Get-SPLogEvent cmdlet is used to search the local Trace logs or merged (Merge-SPLogFile) logs. To search for a Correlation ID the following PowerShell command line can be used.

    Get-SPLogEvent |
    ?{$_.Correlation -eq "2872bd2d-a0a5-4cac-b218-f504a7d2a4c5"} |
    ft Category, Message -Autosize

    This will search the Trace Logs for the Correlation ID and output the category and message of any records in the log related to the id.

    Correlation ID in code

    If you have error handling in your code and perhaps logging information manually to the Trace Logs you can get the current Correlation ID by using a native method called EventActivityIdControl() found in advapi32.dll. You have to import the method like this:

    [DllImport("advapi32.dll")]
    public static extern uint EventActivityIdControl(uint controlCode, ref Guid activityId);
    public const uint EVENT_ACTIVITY_CTRL_GET_ID = 1;

    And then use it in code like below, perhaps in a catch statement

    Guid g = Guid.Empty;
    EventActivityIdControl(EVENT_ACTIVITY_CTRL_GET_ID, ref g);
    this.Controls.Add(new Label { 
        Text = string.Format("An error occurred with correlation id {0}", g)
    });

    Pretty neat! If you like it you can find even more information on the topic in my upcoming book SharePoint 2010 Web Parts in Action.

  • Deployment and security options of custom code in SharePoint 2010

    Tags: SharePoint 2010

    In SharePoint 2010 there are more ways to deploy custom code than in its predecessors, the reason is the introduction of the Sandboxed solutions. There are basically now three different ways to deploy custom assemblies:

    • Full trust solutions, aka Farm solutions - The assemblies are registered in the GAC and runs under full trust
    • Partial trust solutions, aka Web Application solutions - The assemblies are deployed to the bin folder of a specific Web Application
    • Sandboxed solutions, aka User code solutions - The assemblies (solutions) are deployed to the Site Collection gallery

    These are the basic variants of how to deploy custom assemblies. There are actually a few variants of them, but more about them later. So which one should I use and when? Let's go through them all and look at the pros and cons.

    SharePoint 2010 is still in beta (RC for some) and there are no best practices of this. It's hard to create a best practice before the product is released and actually tested in all situations. I guess we have to wait a few months until we have general best practice. Meanwhile consider this...

    Sandboxed Solutions

    The Sandboxed Solutions runs inside the a special service, called Microsoft SharePoint Foundation Sandboxed Code Service, which is a completely and separate application domain than the SharePoint application pools. The Sandboxed solutions are monitored and if they consume to much resources or fails to many times SharePoint automatically shuts the solution down. The code running in a Sandboxed assembly does not have access to the full SharePoint API, basically it's just the classes from Site Collection level and below. The sandbox is also protected with a very minimal CAS policy which for example prohibits the user code solutions from calling web services, making database calls or accessing the file system.

    Sandboxed solutions are deployed into the Solution gallery of a Site Collection and only access that Site Collection. They can be deployed without having any downtime of the farm or web application. Anyone within the Site Collection Administrators group can upload solutions to the gallery and activate them. Farm administrators controls how much resources each Sandbox can use and can also block specific solutions from running at all.

    Pros Cons
    Can easily be deployed by Site Collection Administrators Very limited CAS policy
    Resource usage is monitored * Current uncertainty about the monitoring stability
    Secure Hard to deploy in a farm
    Great support in Visual Studio 2010  
    Only crashes the Sandbox if it blows  

    * There are currently many discussions in the blogosphere and on Twitter about how good the monitoring actually is. There is a timer job running that calculates the resource usage every 15 minutes, by default, and during 15 minutes a lot of things can happen.

    I must admit that I was very skeptical at first to the Sandbox but the more I have tested and experimented with it the more satisfied I am. Also looking at my current day-job assignment I so much would like to have the Sandbox right now!

    Farm Solutions

    The Farm solutions or full trust solutions adds the assembly to the Global Assembly Cache, GAC, which means that they can run without any CAS policies, i.e. under full trust. The assemblies can be accessed from any application in the farm. Full-trust solutions are (was?) the most common way to install solutions since it is easy and requires no knowledge of for instance CAS policies. The code running in a full trust solution has the same access as the application pool account to the local server and can do almost what it want with the server. Deploying Farm solutions should only be done with code that you really trust.

    Only farm administrators can upload new farm solutions to the configuration database and most often an application pool recycle is needed, especially when updating solutions.

    Pros Cons
    Easy to implement Only Farm Administrators can add new solutions (can be a pro also :-)
    Great support in Visual Studio 2010 Downtime when updating
    Runs in full trust Have to much privileges
      Can crash the whole server

    Web Application Solutions

    Solutions deployed to the web application bin directory was the way to go in SharePoint 2007 when you wanted/needed to secure you application using CAS. This partial trust option is still valid in SharePoint 2010. Web application deployed solutions by default only have a very minimal CAS policy applied. Using custom CAS policies it is easy ("CAS is easy!" - Todd Bleeker) to give more privileges to assembly. Installing these solutions also requires a Farm Administrator but they are only applied to specific Web Applications. Updating the assembly does not require an application pool recycle.

    Visual Studio 2010 have support for Web Application deployment but not for custom CAS policies. If you need custom CAS policies you need to hack some XML and you cannot use the F5-debugging experience in Visual Studio. Instead you have to install the solution using PowerShell or create your own Visual Studio SharePoint Deployment Steps.

    Pros Cons
    Security policies can be configured and kept minimal Only Farm Administrators can add new solutions (can be a pro also :-)
    Minimal downtime when upgrading No support OOB for custom CAS policies in Visual Studio 2010
    Only crashes the web application  

    Sandboxed Solutions with User Code Proxies

    There is actually a fourth option of deployment. And that is to use Sandboxed Solutions in combination with a full-trust User Code Proxy. A User Code Proxy is a special assembly and class that is registered in the GAC and running under full trust. This class exposes an operation that can be called by the Sandboxed code. Since it runs under full trust we can easily create a Proxy Operation that calls a web service or access other protected (from the Sandbox) sources. The proxy has to be registered by a farm administrator and is accessible to the whole farm, which means that all developers who knows about the assembly, class and operation can use the operation.

    Since the User Code Proxy runs under full trust you need to be careful about that one. But if you design your application carefully the proxy operations should be kept to a minimum and quite small. This allows you to make the thorough code review on only a fraction of the whole application.

    Tip: Make the User Code Proxies as Farm solutions which are registered using Feature activation and unregistered using deactivation of the Feature. Then your farm administrators can enable and disable them easy!

    My Recommendation

    Which one to choose is up to you, your client and the SLAs. Based on my experience with SharePoint 2010 so far is that I do recommend that you always start with building your solutions as Sandboxed Solutions. If that is not enough then try to add one or more User Code Proxies. Only use full-trust solutions when you have no other option. And pleas do still consider Web Application deployment - even though Visual Studio doesn't have that good support (right now, let's see what the CKS:DEV team have up their sleeves)

    What do you think?

  • Confusing names of commands in SharePoint 2010

    Tags: SharePoint 2010

    If you have been developing with SharePoint for the last few years you probably are very aware of the SPWeb and SPSite naming is a bit confusing. SPWeb is actually a site and SPSite is a site collection. It's always fun explaining this to new SharePoint developers...

    In SharePoint 2010 this naming convention confusion continues and now expands to the administration of SharePoint.

    Let's for example take the example when you are activating or deactivating features. In the web interface of SharePoint 2010 and SharePoint 2007 it is called Activate and Deactivate.

    Feature activation in SharePoint 2010

    The same term is used in STSADM with the activatefeature and deactivatefeature operations when scripting feature activations and deactivations. But STSADM is old-school in SharePoint 2010 right? So we use PowerShell to deploy the solutions, and guess what, there are no cmdlets using the verb activate or deactivate. Instead activate is called enable and deactivate is called disable. This gives us the PowerShell cmdlets Enable-SPFeature to activate a feature and Disable-SPFeature for deactivation.

    And it doesn't stop there if we look at the PowerShell commands. Deploying a solution is called Deploy in Central Administration and deploysolution using STSADM. In PowerShell it is called Install (Install-SPSolution). And it gets better Retracting a solution is called Remove in Central Administration, retractsolution in STSADM and Uninstall (Uninstall-SPSolution) in PowerShell.

    I never said the SharePoint world is easy...and that's why I'm all into it...

  • SharePoint 2010 Web Parts in Action - book site is live

    Tags: SharePoint 2010, SharePoint 2010 Web Parts in Action

    As some of you know I'm writing a book on SharePoint 2010 Web Parts development to be published by Manning Publications. I have set up a site dedicated to this book project where you can follow the progress of it.

    You can find the site at http://www.sharepointwebpartsinaction.com/

    image

    I am currently half way through the writing and we are closing in on the Manning MEAP program. So if you are interested in the latest news on the book head on over to the site...

    By the way: I set up the site using the really promising Orchard CMS system. It's fun once in a while and try something else than SharePoint...

  • What is new with the CssRegistration control in SharePoint 2010

    Tags: Web Parts, SharePoint 2010

    The CssRegistration class (in Microsoft.SharePoint.WebControls namespace) is one of the most useful controls in SharePoint 2010. It existed in SharePoint 2007 but was fairly limited then. I thought I should guide you through why it is so useful in SharePoint 2010 and why and when you should use it. I briefly mentioned the CssRegistration control in my previous post on SharePoint 2010 themable CSS files. But first some background.

    Why the CssRegistration control?

    There are plenty of times when you need to add custom CSS definitions to your SharePoint projects, for instance in pages and Web Parts. There are several methods of adding CSSes to your projects. You could use inline CSS styles - which results in a lot of markup which may slow your page/site down. Another approach is creating a CSS file and include it in your master page - better but the CSS is always loaded.

    The third option is to add a link tag and reference your CSS in your Web Part so it's only loaded when needed. But if you have several of these Web Parts on your page you will reference it several times. A common method is to override the RenderContents method or similar and add the CSS link tag there. Not a good option either and can result in multiple CSS registrations.

    This is the reason for the CssRegistration. This control registers the CSS files with SharePoint and once it is time to render the page it only renders one link tag for each, even though you might have registered the same CSS file multiple times. It is the CssLink control that is responsible for the actual rendering and this control is normally placed in your master page.

    The CssRegistration control existed in SharePoint 2007 and it was somewhat useful in removing duplicate CSS links. The problem is that the CSS files and rules are processed in the order that the links appear and the SharePoint 2007 implementation always rendered the CSS files in alphabetically order.

    CssRegistration in SharePoint 2010

    The new implementation of the CssRegistration have a number of new features. First of all you can specify the order using the After property. The After property contains the name of the CSS that you want to place the CSS after.

    Registering two CSS files like this:

    CssRegistration

    would yield the following output CSS order on a Team site:

    1. myCss.css
    2. myCss2.css
    3. wiki.css
    4. corev4.css

    Adding the After property to the controls like this, so that out myCss2 is rendered after corev4 and myCss after myCss2.

    CssRegistration and After

    would yield this order:

    1. wiki.css
    2. corev4.css
    3. myCss2.css
    4. myCss.css

    Pretty smooth!

    Another useful new feature of the CssRegistration is that you can add Conditional-CSS expressions so that you can target the CSS files to different browsers.

    CssRegistration and ConditionalExpression

    By adding the ConditionalExpression parameter to the control we tell the CssLink to render the Conditional-CSS code as well as the CSS link. The result of the registration above is:

     Conditional Expression

    If you are targeting a non Internet Explorer browser you should also set the RevealToNonIE  parameter to true.  The reason is that the syntax is not valid XHTML syntax and the extra parameter will add some extra HTML comments to make it valid XHTML. Read all the details on Wikipedia.

    The CssRegistration control also has a parameter called EnableCssTheming that allows your CSS to be themed, which I showed in the previous post.

    I hope this little CssRegistration tutorial was useful - I think it's one of the great improvements in SharePoint 2010!

AWS Tracker

About Wictor...

Wictor Wilén is a Director and SharePoint Architect working at Connecta AB. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for four consecutive years.

And a word from our sponsors...

SharePoint 2010 Web Parts in Action