/ #SPCAF #tips&tricks 

Ramp up your SharePoint packages with SPCAF

After implementing SPCAF you will probably hit some errors and warnings, I know I did. Some of these errors you should fix, while others can be ‘ignored’ or are a design choice you made while implementing your application. When I first started to use SPCAF I had a few errors that bugged me a bit since they occurred due to using some of the default artifacts Visual Studio provide to you. So when I started using SPCAF in my projects I encountered three things that can be fixed fairly easy and will help you getting a better solution:

  • Do not deploy solutions globally

    • Declare attribute ‘Title’ and ‘Description’ in Solutions

      • Declare attribute ‘SolutionId’ in Feature
      All three can be fixed by using replacement parameters in Visual Studio, so that you do not have to ‘hardcode’ anything, it just takes a few minutes to figure out what should be used where.

    The first two things are related to the solution package, while the last one is related to your feature XML. On MSDN you can find an overview of all the replaceable parameters for SharePoint 2013, and in my case the replaceable parameters for SharePoint 2010.  

    Now if you would open your package XML you would see the following:

    <?xml version="1.0" encoding="utf-8"?>
    <Solution xmlns="http://schemas.microsoft.com/sharepoint/">

    So for changing the Title and the description you can use $SharePoint.Package.Name$ and the $SharePoint.Package.Id$. and that will get you ending up with something like the following:

    <?xml version="1.0" encoding="utf-8"?>
    <Solution xmlns="http://schemas.microsoft.com/sharepoint/" Title="$SharePoint.Package.Name$" Description="Package ID: $SharePoint.Package.Id$">

    The goal of deploying a solution to a certain webapplication can be achieved by adding a safe control. Adding a safe control will convince the SharePoint deployment process to recognize the solution package as a webapplication scoped solution instead of a globally deployed solution. The good thing about scoping a solution package to a single webapplication is that SharePoint will no longer recycle all application pools when deploying.

    Adding a safe control to your package xml will make your complete package xml look like:

    <?xml version="1.0" encoding="utf-8"?>
    <Solution xmlns="http://schemas.microsoft.com/sharepoint/" Title="$SharePoint.Package.Name$" Description="Package ID: $SharePoint.Package.Id$">
    <Assembly Location="$SharePoint.Project.AssemblyFileName$" DeploymentTarget="GlobalAssemblyCache">
    <SafeControl Assembly="$SharePoint.Project.AssemblyFullName$" Namespace="$SharePoint.Project.FileNameWithoutExtension$" TypeName="*" />

    For updating the solutionid attribute in your features you can use the same parameter as in the package; $SharePoint.Package.Id$. So you can use a feature xml that looks like:

    <?xml version="1.0" encoding="utf-8" ?>
    <Feature xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="$SharePoint.Package.Id$">

    Using the Solution Id will help you what solution deployed a feature and can come in quite handy in your deployment and upgrade process. So with these three fixes you will upgrade your package and will provide you with a package with a few less errors.

    Now you might also see an error if you do not specify a version number in your features, even though SharePoint recognizes an empty version as it would be better to provide that yourself..

    And finally make sure that if you are running against a SharePoint 2010 project that you use a 2010 ruleset, getting ‘do not call deprecated methods or properties’ will pop-up if you use stuff that is deprecated in 2013 but is not in 2010, that took me a few minutes figuring out why I had errors the first package I analyzed.