C#, JavaScript, Web Services

JSON and the JavaScriptSerializer

Today I was trying to write a web service method that would allow me to run some stored procedures on my table. Rather than having multiple web service calls for each stored procedure I wanted to come up with some generic functions that could call a range of stored procedures:

  1. Scalar
  2. NonQuery
  3. Retrieve DataTable

Each of these stored procedures require a Stored Procedure name and a collection of SQL Parameters. I decided to instead take a JSON string which would be easy to create from the client and easy to parse on the server.

Here’s the JSON snippet that I came up with

    "procName" : "sp_updateUser",
    "procVars" : 
              "paramName" : "firstname",
              "paramValue" : "jasonscript",
              "paramDirection": "Input"
              "paramName" : "planet",
              "paramValue" : "Earth",
              "paramDirection": "Input"

Pretty simple. Then in my web service I created two classes:

  1. for my container
    internal class Proc
        public string procName;
        public List<ProcArg> procVars;
        public Proc()
            this.procName = "";
            this.procVars = new List<ProcArg>();
  2. for my parameters:
    internal class ProcArg
        public string paramName
        public string paramValue
        public string paramType;
        public ProcArg()
            this.paramName = "";
            this.paramValue = "";
            this.paramType = "";

Next step was to parse the JSON string to these classes

var jsSerializer = new JavaScriptSerializer();
var spInfo = jsSerializer.Deserialize<Proc>(json);

Now I can access everything from my JSON string in my spInfo object

spInfo.procName               == "sp_updateUser"
spInfo.procVars.Count         == 2
spInfo.procVars[0].paramName  == "jasonscript"
spInfo.procVars[1].paramValue == "Earth"

The JavaScriptSerializer will attempt to match the keys of the JSON string to the public properties of each Class.

JSON.procName                 == Proc.procName

These mappings can be altered using DataMember attributes. For example, I could re-write the Proc class as follows:

internal class Proc
    [DataMember(Name = "procName")]      // specify the name to use for serializing
    public string spName;                // renamed so no longer matches JSON snippet
    public List<ProcArg> procVars;

    public Proc()
        this.spName = "";
        this.procVars = new List<ProcArg>();

Thanks to the DataMember property, the JavaScriptSerializer can still map the JSON string to the class property

JavaScript, SharePoint

Javascript and Working with the SharePoint 2013 People Picker

The People Picker in SharePoint 2013 has had a bit of a face-lift.

The ‘Verify Address’ and ‘Address Book’ icons are gone and what’s left is a cleaner, simpler interface.

But new controls means that some of the older approaches to working with the People Picker no longer work.

As usual I’m working with SharePoint 2013 on the client side (CSOM) working with JavaScript and jQuery.

Here are some of the results that I’ve found

Continue reading

Powershell, SharePoint

Programmatically create custom Role Definitions with Powershell

Here’s some information on SharePoint Role Definitions

Role Definitions can be created quite easily

$spRoleDef = New-Object Microsoft.SharePoint.SPRoleDefinition
 $spRoleDef.Name = "Custom Permission Level"
 $spRoleDef.Description = "This is the description of a custom Permission Level"
 $spRoleDef.BasePermissions = ("ViewListItems","AddListItems","EditListItems")

However, I kept getting SharePoint errors when I ran this script

Exception calling "Add" with "1" argument(s): "You cannot customize permission levels in a 
web site with inherited permission levels."
At line:38 char:17
+ $Web.RoleDefinitions.Add($spRoleDef);
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
 + FullyQualifiedErrorId : ArgumentException

Again, this seemed like one of those common issues because there were a lot of posts online about how to fix it. You have to break inheritance with the site’s parent.


This makes perfect sense. If you’re inheriting from the parent then obviously you can’t start adding your own custom Permission Levels.
The problem was that this didn’t work for me. I kept getting the exact same error as before

What I misunderstood was that there are different types of inheritance:

  • There are the Users and Groups that have been assigned to the List
  • and then there are the Permission Levels that can be assigned to the Users and Groups

It is the Permission Level inheritance that needs to be changed.

$spWeb.RoleDefinitions.BreakInheritance($true, $true)

Once that was done, then the Permission Levels could be created

Powershell, SharePoint

Starting the Microsoft SharePoint Foundation Sandboxed Code Service

I was trying to write a Powershell script that would deploy several features to a SharePoint 2013 environment but I kept getting an error:

Error occurred in deployment step ‘Activate Features’: Cannot start service SPUserCodeV4 on computer ‘SERVERNAME’

A Google search revealed that this was quite a common problem with quite a simple fix:

  1. Open the Central Administration site
  2. Open System Settings and click on Manage Service on server
  3. Check to see if Microsoft SharePoint Foundation Sandboxed Code Service is running (it should be stopped)
  4. Start the service and retry deploying the Sandboxed solution.

The problem I had was that I was using Powershell to do my deployment and didn’t want to have to include any manual steps. Unfortunately I couldn’t find any blogs that discussed how to do that.

Continue reading

JavaScript, SharePoint

SharePoint Dialog Page – Opening a Custom Page

Recently I learned something new while working with SharePoint 2010.

I was working with a SP List’s NewForm page and was restricted to working on the client-side only (i.e. No server side code / web parts).

The basic scenario was that I had a List of Issues. Each individual Issue could then have related Issues.
So our List basically looked like:

  • Issue ID
  • Issue Name
  • Related Issues (IDs)

The customer didn’t like the default lookup controls to select the Related Issues because they could have a LOT of Issues in the system at any one time (600+ Issues) and the default controls don’t really allow the user to filter, sort or do any other wonderful SharePoint things that we can normally do on a List.

SharePoint Standard UI
SharePoint Standard UI

The solution that we came up with was to utilise JavaScript and try to improve the UI a little.

Continue reading