Chronicles of a Chronic E-Junkie

AppFabric Caching and Custom Solutions in SharePoint 2013

2013-07-01T22:05:00.001+01:00

So you should've heard by now that SharePoint 2013 uses the AppFabric Distributed Caching mechanism to (finally) manage caching across multiple nodes in a SharePoint farm.

Awesome.

So does that mean you can use it for your custom apps? Absolutely not, according to TechNet: http://technet.microsoft.com/en-us/library/jj219572.aspx

If you are using custom applications in SharePoint Server 2013 which use the AppFabric client APIs, or are creating custom caches, you should create a separate AppFabric cache cluster to support your custom applications. Do not use the AppFabric cache cluster supporting your SharePoint Server 2013 farm. Run your separate AppFabric cache cluster for your custom applications on separate servers from the servers dedicated to your SharePoint Server 2013 farm.

Basically, this means if you want something resembling a reliable* distributed cache store to hold a lot of data that you need quickly, you'll need to stand up more Windows servers if you want to use AppFabric.

* = 'reliable' as in, accessible from any server. It's not "shared nothing", and doesn't have anything resembling MapReduce, so it's an extremely volatile store. Think of it as HttpRuntime.Cache but code can access keys from any server in the cache cluster.

Find SharePoint Pages That Use a Specific Page Layout

2013-06-17T13:03:00.002+01:00

When you try to delete a page layout that's in use, SharePoint will warn you (or rather, blow up on you) that it's currently in us, but rather unhelpfully doesn't tell you which pages are using it.

Luckily, a little-known feature in SharePoint that has existed since SharePoint 2007 will list you all the pages that are using a Page Layout.

To get to it, navigate to your site collection's top level site, open up Site Content & Structure from the Site Actions menu in SharePoint 2007/2010 (or under Site Administration section of Site Settings in SharePoint 2013).

Once it has loaded up, select your Masterpage Gallery.

Then, from the toolbar along the top of the right hand pane, click 'Show Related Resources'.

A panel will open up at the bottom which shows all the items/documents in the site collection that use the currently selected item, and other items/documents that reference the selected item. Select your desired Page Layout, and you'll see Pages that are being used, with the column value 'Used By' along side.

This view does traverse the entire site collection and will show you all pages in all sites that reference this page layout.

Unfortunately, this won't work for masterpages, so you can't see what sites use a given masterpage - this panel will only show List Items (or Documents) that have a reference to a given file.

Setting Page Ratings using SharePoint Client Object Model

2013-06-13T15:20:00.002+01:00

Want to set the Rating for the current page yourself with JavaScript?

Here's how. You will probably need to build your own rating control to get the rating for the current page and render it nicely, but until I figure out the SP JavaScript to update the OOTB control, here's the code for actually setting the rating:

(function () {
    var listId = _spPageContextInfo.pageListId;
    var itemId = _spPageContextInfo.pageItemId;
    var rating = 3; // Make sure you set this to what the user wanted
 
    EnsureScriptFunc('reputation.js',

        'Microsoft.Office.Server.ReputationModel.Reputation',

        function() {
            var ctx = new SP.ClientContext();
            rating =

            Microsoft.Office.Server.ReputationModel.Reputation.setRating(ctx, listId, itemId , rating);

            ctx.executeQueryAsync(done, fail);
        });
            
    function done() {
     //alert("Done");

        // Handle something here, like updating the UI of your rating control.
    }
    
    function fail() {
     //alert("Failed");

        // If it fails for whatever reason, dump it in the console for debugging,

        // or tell the user
    }
            
})();

SharePoint 2013 Design Manager - It Kinda Sucks, It's Kinda Good

2013-06-03T13:30:00.002+01:00

SharePoint 2013 has touted quite a few new features which allegedly 'enable' developers from more web design backgrounds to work in the platform. There is an encouragement to use more modern development techniques such as pure JavaScript and HTML to use technologies like REST to develop applications. And fitting in with this trend is the encouragement of web developers to be able to create designs for SharePoint sites without needing to know too in-depth knowledge about ASP.NET web forms, particularly how MasterPages and SharePoints Page Layouts work.

The Design Manager steps in as promising to "makes it easier to create a fully customized, pixel-perfect design while using the web-design tools that you're already familiar with.". Now, designers were able to this perfectly well in previous versions of SharePoint, granted that they became familiar with dealing with extremely bloated markup, most of which SharePoint needed to provide its rich functionality. All we had to do was learn which bits never to remove and to build designs in and around the dozens and dozens of lines of code that SharePoint uses. Randy Drisgill has kept the design world in SharePoint much more manageable with his stripped-down master pages which contain only the markup that SharePoint needs to get itself working.

The general idea...

In this post I'll go through my own experience of using the Design Manager, how it compares to what the tutorial actually recommends you do, and how I reckon it would work in real life. More importantly, if the Design Manager really is the better way forward for designers to go. (Spoiler: Yes. Yes it is. In my opinion.)

The tutorial I'll follow is detailed on MSDN here: How to: Convert an HTML file into a master page in SharePoint 2013 which covers the first and main thing we encounter when branding a site - building a masterpage.

The general workflow of using the design manager is as follows:

Create a static HTML Mockup of how you want the site to look
Convert it into a masterpage
Add SharePoint functionality using "snippets"
Preview & Fix Issues

The main promise is that you can use your favourite HTML editor to create, fix and maintain your masterpage. You could do this before by editing .master files, as I said before, but there is one benefit now that comes into play that has a slight sting in its tail, but once you get used to it it may actually be a better way of working.

What really happens is that SharePoint generates a .master masterpage file from your uploaded HTML markup file. The HTML markup file is then linked to that masterpage file. Any changes you make to the HTML file cause the .master file to re-generate. You can edit the resulting .master file if you want by unlinking from the HTML (it's a list item property of the HTML file, called 'Associated File'), but then changes to the master file are lost when you re-associate.

Trying it out

So to begin with, I started off with a nice little HTML mockup of a very simple design I created. I called it SampleDesign. Here's how the markup looks in my favourite HTML editor (Visual Studio 2012, which is a damned good HTML editor nowadays).

Now it's off to the Design Manager to upload. And this is where things get interesting. As the MSDN Documentation says, SharePoint will add some markup to your page when it's converted to a masterpage. Upload the file to somewhere in your masterpage gallery (preferably in its own folder in the gallery) then use the 'Convert an HTML file to a masterpage' option under 'Edit Master Pages' within the Design Manager. Once you've done this, open the file you uploaded, using your favourite HTML editor.

Whoa. Comment blocks everywhere! And this is one of the slightly nicer things about this method - no longer will your editor complain about lots and lots and lots of SharePoint ASP.NET tags all over the place, these are all commented out.

Now the next thing to do is to take your design, replace out all the 'stub' content in your page with the SharePoint-Provided Snippets. Let's replace my site title in the H1 tag with the snippet provided in the design manager. But wait, here's our problem. Our beautifully simple design has been way too cluttered with SharePoint stuff. Lets add the snippet to our original, simple design mockup that's stored locally, by copying and pasting (ignore the fact I've stuck a div inside an H1).

That was relatively simple. Lets see what happens when we re-upload this to the site:

That's.... not bad. A little less painful than trying to figure out where in the muddle of all the markup that snippet was supposed to go.

But here we have a problem. We have a disconnect between our beautifully simple HTML mockup we created, complete with snippets, and the 'live' SharePoint copy of the masterpage. What do we do? Microsoft recommends that we connect a shared drive to the masterpage gallery and let us edit the HTML masterpage directly from the gallery, yet it's full of comments and snippet code already injected by SharePoint.

Well what seems to make sense to me is to first design your simple HTML mockup. Then go into the Design Manager and get the snippets you need, and then insert them. Make sure you have ALL of the ones you think you will need for your design. Try to make the HTML markup that you have to upload as final as possible, in that you have the layout and snippets all in place, and have resolved some of the HTML markup issues using the Preview button. Keep as much control of the layout in CSS as possible (which is a good design practice anyway).

That way, once you've uploaded the HTML file and SharePoint has converted it into a masterpage, you can continue to tweak the design directly on the server by only modifying the CSS files for your design.

Another thing that makes this whole method slightly more encouraging is what SharePoint does to generate the Ribbon - It's a single line of SharePoint snippet. This vastly reduces the bloat we used to have in the classic masterpages, but they still could have done it better by doing something similar with all the controls needed within the HEAD tag.

Another snippet

Lets add another snippet and try out this workflow again. This time I'll add a searchbox snippet:

Nice and easy, got my referenced CSS file in there too to stick it up on the right:

Upload it back to the masterpage gallery, and have a look at the converted markup....

As predicted, it's converted everything nicely. Lets see how the Visual Studio Design View treats this, just out of curiosity...

... not so fantastic. Might as well stick to the code view and use the Design Manager Preview to see how things are going...

... that's a little better.

Validation

Now, the MSDN tutorial recommends you upload a valid XML file. Fair enough, but lets see how 'valid' our bare HTML mockup is with just the added snippets from the SharePoint site (not the generated HTML masterpage, but the one we started with, and then added to):

That's not too good. Ignore the 1 error I made by putting a div within an H1 tag, the rest are all to do with SharePoint's attributes that it's added (such as div webpartid=... ).

The Workflow as I see it

So, to summarise the workflow as it appears to work best:

Design your HTML mockup for the masterpage as complete as you can make it.
Use CSS extensively to control layout (as you should be)
Add all the SharePoint snippets you will need to the appropriate areas
Upload to the masterpage gallery, in its own folder for the design
Convert it to a masterpage using the design manager
Use the Preview tool to find and sort any problems.

Try to use the CSS files for your design to sort the issues where you can, but if you have to change the markup, then do so in your original, local file then re-upload.
Try to make the uploaded HTML file a 'final' kind of copy.

Publish it. Then get ready for deployment.

Design Packages

So now you've got a design just the way you want it, and now you need to push it somewhere else. Enter the Design Packager. This generates a WSP file that will live in the Solutions gallery (Sandbox definitely not out of the picture then, especially if the Design Manager continues to live on in the next version of SharePoint). Bare in mind that when you create a design package, it saves it in the Solutions gallery of the site but doesn't activate it. It's probably not wise to activate it on the site you created it in anyway.

Download it, upload it into the destination site and activate it. When I first did this I got an error (see right), but when I looked at the Solution gallery it seemed to be activated anyway. So no harm done (it seems).

It'll create the files/folders in the masterpage gallery. You can then see it available when you access the 'Assign master pages to your site based on device channel' option, on the Publish and Apply Design page of the Design Manager. This page just happens to be the classic ChangeSiteMasterPage.aspx of yore. If you don't see it here, you might have to Publish and Approve the masterpage HTML file. Don't do this on the generated .master file, they are linked.

Publish the HTML file and both the html and master go to 'Pending'...

... mark the HTML as approved and they both go to 'Approved'.

In Summary

So - good things (in my opinion) about the design manager:

Lets you edit HTML markup to describe a page layout, rather than a messy ASP.NET master page
Lets you package and deploy all assets needed for your branding solution

Bad things:

If you want to keep as much readability as possible, you will need to maintain a local / source-controlled version of your mockup, complete with inserted snippets.
Snippet markup could probably be a bit more terse and lightweight. Your HTML is still a bit polluted.
What you end up editing still isn't fully valid HTML5, so your editor might complain. But hopefully not as much as before.

Would I use it in real life?

... maybe. I'm not a designer at heart, but I can implement a flat design concept. I like the ability of being able to do most stuff within the site itself and then being able to package it and deploy it elsewhere. A lot of the time in Visual Studio doing this before was spent in getting the solution to do what I want, activating features and such. This has now been simplified greatly, if I use this technique.

SharePoint from iOS - a new library - SPMobile

2013-05-24T17:30:00.002+01:00

Cut to the chase: github is here: https://github.com/jimmywim/SPMobile

I have spent a bit of time recently tidying up and expanding the code possibilities with my iOS library - SPRESTApi.

The changes have allowed me to extend it so it's no longer just a REST API helper, but can be used to called the ASMX web services in SharePoint. This effectively lets it work with any version since SharePoint 2007.

And in order to enable it to work with all the way back to 2007, I've extended the authentication mechanism to be able to log in using Forms Based Authentication.

I have therefore refactored the code quite a lot and created a new Github repository - available here: https://github.com/jimmywim/SPMobile (I've also learnt a fair bit more about Git since my last try too, now quite enjoying it! :D)

Code samples of authenticating into FBA and executing web service requests are all on the README on the Github site.

With reference to my last blog post, this is confirmation that I'm no longer maintaining SPRESTApi, but I'll keep it there for future reference (and for historical purposes, so I can laugh at my poor learning of git in the future).

SharePoint Forms Authentication (FBA) with Apple iOS

2013-05-14T23:26:00.000+01:00

Over on my Github project I have finally got round to doing some updates to the code. I've added a class that simplifies Forms Authentication, and allows you to issue the same REST API queries against SharePoint.

Code samples are on the wiki on the Github site.

Doing this wasn't really that difficult, you basically execute a SOAP operation on /_vti_bin/authentication.asmx - calling the 'Login' operation. The envelope payload you pass in isn't complex, just the username and password structured in the required XML (to see details of that, just visit the asmx url on any SharePoint Farm then click 'Login' to view the signature and response format. Once your request with a valid payload is completed, and if you're authenticated, you get a response which contains your FedAuth cookie. Just keep a hold of that, add it to every other request to the site and you're effectively logged in. Simple!

I've also modified the SPRESTQuery class to allow you to specify the SOAPAction and payload, which effectively lets you execute the classic ASMX web services - and thus makes it work with SharePoint 2010. Because of this, I'm thinking of renaming the project and refactoring a lot of the code to make a simple 'SharePoint Connectivity Library for iOS'. Not sure when I'll get round to doing this but hopefully sooner rather than later (it's been 5 months since I started this project and made the first batch of code commits!). So, as I say on the README, 'watch this space'.

In summary of what I envisage the project/library to end up as - a helper class which will let you authenticate into SharePoint, persist the authentication cookies to keep you 'logged in', and to help you issue remote requests to the available client-side APIs (specifically, ASMX web servies and the REST API in 2013).

It currently doesn't support NTLM, but this is something I do plan to include at some point.

Failed to load the appropriate report editor - PerformancePoint Server 2010 and SSRS 2012

2013-05-13T12:02:00.001+01:00

If you are running PerformancePoint Server on SharePoint 2010, and have installed SSRS 2012, you will notice that you cannot edit any SSRS Reports within Dashboard Designer, you'll get the following message:

"Failed to load the appropriate report editor. Please verify the appropriate plug-in is installed.

Sometimes (though not always) you get this warning which helpfully gives you the link to the SSRS 2008 R2 Report Viewer utility.

If not, here's the link anyway: Microsoft Report Viewer 2008 SP1 Redistributable.

SSRS 2012 does indeed install its own version of the Report Viewer assemblies, but PPS will only look for a specific version (that for SSRS 2008).

Install this (the 2008 R2 version) and restart Dashboard Designer. You should now be able to edit SSRS ReportViews.

Creating Custom PerformancePoint Reports in C#

2013-04-25T10:00:00.000+01:00

(Concepts here are discussed around SharePoint 2010 but should equally be applicable to SharePoint 2013. All concepts here apply only to full-trust farm solutions, and cannot be done at all with Sandboxed solutions or with the App model)

Occasionally you might give given the requirement (as a developer) to provide the ability to insert a chart in PerformancePoint that cannot be done with any other technology available to us (like SSRS, Excel Services, or even the native PerformancePoint charts).

An example of this (and this is a real-life example) was the scenario where a customer wanted a chart where their users could select the axes for the chart at run time, but really this could be any kind of chart or some other data display that just isn't available within the regular Excel Services or SSRS capabilities. You've probably been through the spec and know it's possible, or even trivial, to create the type of display that you need using standard .NET Framework controls (such as WebParts, etc).

However, in order to make this a real part of PerformancePoint Server, including the ability to use this chart within Dashboard Designer for both design and deployment purposes, we need to make use of the PerformancePoint Services Code Samples. These are already available on MSDN and they are documented. However I found the documentation was a bit dense and difficult to read for particular scenarios.

The MSDN Documentation - a critique
The SDK for PerformancePoint (not the official title) describes how to create custom Tabular Data Sources, custom Filters and custom Reports. At this stage I don't think it's possible to create custom Scorecards. Note that while the MSDN Documentation refers to these custom objects as 'Extensions', the are really distinctly separate and new objects (whose underlying functionality inherits from the custom type you're defining), each are individually available within Dashboard Designer and are individually configurable.

Another thing to point out is that you may see references to 'FCO' or 'First Class Objects'. This refers to anything in PerformancePoint, such as DataSources, Charts, Filters, Scorecards, etc. The SDK does not let you create new FCO types, but it lets you create new FCOs that extend existing ones. For example, there is an FCO type of ReportView, and PerformancePoint out of the box lets you create new SSRS Report Views (otherwise known as Analytical Report Views), Excel Services Report Views, and even a 'Web Page Report View' (which is really just an IFrame that can be added to a PerformancePoint Dashboard). The sample project linked at the end of this article will create another type of Report View which we can use in Dashboard Designer.

One of the things I disliked about the documentation on MSDN about this was the deployment model. The steps tell you to 'sign the assembly' and then 'deploy to the GAC', as well as putting the Editor ASPX pages directly in the LAYOUTS directory in your 14 hive. These are all parts which are handled for you if you use the Visual Studio SharePoint project template. The only part of the deployment you will have to do manually is modifying the web.config file of the Monitoring Server endpoint. The attached solution contains a ReadMe.txt file in the Configuration folder describing how to do this to enable the functionality within that solution. The attached solution is also a SharePoint Project, which should easily be deployed to your development environment.

Another point is that on this page (http://msdn.microsoft.com/en-us/library/ee557288(v=office.14).aspx) there is a line towards that end that calls SPDataStore.GlobalDataStore.GetReportViewForExecution(elementLocation); however the method here appears to be an Extension Method and none of the instructions tell you what assembly it's in, or even if it still exists (as I couldn't find it). In my code sample, I have replaced this method with just GetReportView() and this seems to work just as well.

The Nuts & Bolts
So, despite the complexity of the documentation or the poor deployment model described therein, creating custom ReportViews for use in PerformancePoint Server is actually very straight forward.

Essentially, there are only two parts to this (at least, only two parts to the PerformancePoint specific side of things. Your charting or display requirements could be more complex, but the actual bits to get it working in PerformancePoint only require these two bits).

You need a Renderer class and an Editor page.

Do pay attention to the details on creating these. Use the code samples they provide (along with the Helper classes) as templates for your own customisations. Doing so is a recommended practice as documented on MSDN. All of the helper classes provided on MSDN are included in my sample solution. I have modified the Renderer class to simplify the code to make it somewhat easier to read, although the sample code on MSDN will display every detail about the filters connected to the report.

The Editor Page is a basic ASPX page, but this could just as easily be a SharePoint Application page, as long as it performs the necessary tasks to the underlying PerformancePoint object (in this case, the ReportView object).

When using the Editor Page the make changes to your Report, and you've clicked 'OK' and returned back to Dashboard Designer, you will have to Refresh Dashboard Designer in order to load the changes you've just made into Designer. This is because the Editor Page lives in SharePoint and isn't a series of Forms in a wizard like the native reports. This is a minor annoyance but once it becomes habit you tend not to notice as much.

Within the Renderer class, you'll notice I'm explicitly checking for and displaying the value of the MemberUniqueName and MeasureUniqueName columns (the latter is a custom one I've added into Tabular filters I'm using elsewhere in my environment). I've yet to figure out how to get the value of whatever column was specified at run time, though this must be available somehow (I've just yet to find out where). Modify the code as you need, or if you can, discover how to get just what was specified in Dashboard Designer.

When developing your custom charts, do keep in mind maintainability and try to keep your code lightweight, and reduce dependencies. Try not to do all of the logic to draw the charts within the Chart Renderer class. Do your heavyweight logic within a separate class, such as a WebControl class or similar, then simply use the Chart Renderer to instantiate your separate class, and call the RenderControl method of that instance. This should keep your PerformancePoint-specific code more maintainable.

EndPoints
A note on EndPoints - the way I have implemented EndPoints is to simply store a semi-colon separated list of EndPoint names in the reports CustomData property, which will be used to dynamically generate the EndPoints to which you can attach filters. The ReportView class which you have to use does not seem to allow adding extra properties (Though you may be able to inherit the ReportView class and add your own, I have not tried this, but I'm not certain if the extra properties you add will be serialized - if they do then that is excellent - just extend the ReportView class into your object model and add the properties you need).

Like I said earlier, you would ideally separate the logic for rendering your custom report away from the custom Renderer or Editor classes. This separate logic would have it's own requirements for how to draw the content, and what input data it needs (such as the path to an XML file perhaps). Your custom logic can then somehow expose the EndPoint information to dynamically create EndPoints in the Report (see CustomReportEditor.cs Line 236 for an example of generating the EndPoints).

Note that in the Renderer class (in my example) there is little reference to the EndPoints themselves, rather the ParameterMessages object which contains the filter values that have been passed in.

If you don't want to inherit ReportView or can't, then you can use the ReportView.Properties collection to create, store or read Properties for the report instance. These can be viewed and edited in Dashboard Designer on the Report Properties page. Keep in mind that you will need to cast the Property you want to create/edit/read to the correct BpmProperty type, and there are some available for storing different data types such as Text or DateTime. Try to use the correct one so your property values are correctly serialized.

Do let me know if you can't get the Sample Code to work right, or if you spot any problems in the sample I've given.

Resources:
Link to my code sample (CustomPPSReport.zip): https://skydrive.live.com/redir?resid=C0F61214D82AC938!1809&authkey=!ACtgiRr81oxM-fs

Create Report Extensions for PerformancePoint: http://msdn.microsoft.com/en-us/library/bb837254(v=office.14).aspx

PerformancePoint Services Code Sample: http://msdn.microsoft.com/en-gb/library/ee558401(v=office.14).aspx

Get All PerformancePoint Filter Value selections in a Site Collection For the Current User

2013-04-22T10:00:00.000+01:00

Here's some code to get all PerformancePoint filter selections for the current user in a web site.

This is a fairly straightforward operation. First you need a collection of strings, each of which is the URL to a PerformancePoint Filter stored in SharePoint. In this code snippet I use SPSiteDataQuery (in the DiscoverFilterUrls() method). You might want to cache this, though in my implementation where I use this code I'm using the singleton pattern to instantiate this class and to store an in-memory copy of this data.

Once you have this collection of URLs, you need to iterate over them and use the PerformancePoint Monitoring API to get the Filter instance defined at that URL, and call the GetFilterDisplayData method. This will return a DataTable of the filter options. Note the useSavedUserSelections parameter, if I set this to true I will get the saved user selections, otherwise this should return all the options available in the filter. You might also want to do this, just modify the code as needed.

In my code I'm looking for the 'MemberUniqueName' column, as I'm dealing primarily with MDX Member Selection Filters in PerformancePoint, and these contain this column. You may have to modify the code in your implementation to extract the appropriate column.

I have a utility method in here which I use when generating the Dictionary of filters and their values, called IsFilterEncodedInSet. In my implementation, my web.config has an AppSetting called 'ChartParametersEncodedAsSet', which I define a semi-colon separated list of PerformancePoint Filter Names which are passed in as sets. You can find out another way how to do this that's either more dynamic or more configurable (like storing in a SharePoint list). The only reason I use this method is to find out if I need to wrap the filter options in curly braces ('{' and '}') or not. This is important as MDX member sets are defined like this, and thus makes this utility class more general to allowing either single MDX member options or sets of MDX members. Note, however, that an MDX set can easily just contain a single member. My requirement needed me to only include the braces for multiple-member sets. If you have no such requirement for this, you can wrap every filter value that is returned in curly braces quite safely, and remove the dependency on the IsFilterEncodedAsSet method, and thus remove the dependency on the web.config AppSetting.

Let me know in the comments if you have more questions about this code snippet or having problems getting it to work.

Have fun!

  
namespace MySampleStuff.PerformancePoint
{
    using System;
    using System.Collections.Generic;
    using System.Collections.Specialized;
    using System.Configuration;
    using System.Data;
    using Microsoft.PerformancePoint.Scorecards;
    using Microsoft.PerformancePoint.Scorecards.Store;
    using Microsoft.SharePoint;

    /// 
    /// A class that can get filter values from PerformancePoint
    /// 
    public class FilterClient
    {
        /// 
        /// The filter urls
        /// 
        private List filterUrls;

        /// 
        /// The filter values internal
        /// 
        private Dictionary filterValuesInternal;

        /// 
        /// The site
        /// 
        private SPSite site;

        /// 
        /// The web
        /// 
        private SPWeb web;

        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// The SharePoint Site which contains the Filters.
        public FilterClient(SPSite site)
        {
            this.site = site;
            this.web = site.OpenWeb();
            this.DiscoverFilterUrls();
        }

        /// 
        /// Gets the PerformancePoint filter values in the given SharePoint Site
        /// 
        /// A Dictionary of filter names - filter values
        public Dictionary GetFilterValues()
        {
            // return null if not configured
            if (this.web == null || this.site == null || this.filterUrls == null)
                return null;

            //if (this.filterValuesInternal != null)
            //    return this.filterValuesInternal;
            this.filterValuesInternal = new Dictionary();

            SPDataStore bistore = SPDataStore.GlobalDataStore;
            IBIMonitoringServiceApplicationProxy biservice = BIMonitoringServiceApplicationProxy.Default;
            
            foreach (string url in this.filterUrls)
            {
                RepositoryLocation filterLoc = new RepositoryLocation("/" + url);
                Filter filter = bistore.GetFilter(filterLoc);
                ParameterDefinitionCollection parms = filter.BeginPoints;
                ParameterDefinition filterParm = null;

                foreach (ParameterDefinition parm in parms)
                {
                    // "DisplayValue" filters mean MDX Member filters, StaticList filters are SQL Table filters
                    if (parm.DisplayColumn == "DisplayValue" || parm.ParameterProviderId == "StaticList")
                        filterParm = parm;
                }

                if (filterParm == null)
                    continue;

                DataTable displayData = biservice.GetFilterDisplayData(
                    filterLoc, filterParm, new List(), true, true, null);

                string selection = string.Empty;
                bool isMultiple = this.IsFilterEncodedAsSet(filter.Name.Text);

                foreach (DataRow row in displayData.Rows)
                {
                    if (displayData.Columns.Contains("MemberUniqueName"))
                        selection += row["MemberUniqueName"].ToString() + ",";
                    else if (displayData.Columns.Contains("MeasureName")) // specifically for Boston MAtrix, may be reused elsewhere
                    {
                        selection = row[0].ToString();
                        if (!this.filterValuesInternal.ContainsKey(filter.Name.Text + " Caption"))
                            this.filterValuesInternal.Add(filter.Name.Text + " Caption", row["MeasureName"].ToString());
                    }
                    else
                        selection = row[0].ToString(); // All other 'sql table' type filters
                }

                selection = selection.TrimEnd(',');

                if (isMultiple)
                    selection = "{" + selection + "}";

                if (!this.filterValuesInternal.ContainsKey(filter.Name.Text))
                    this.filterValuesInternal.Add(filter.Name.Text,selection );
            }

            return this.filterValuesInternal;
        }

        /// 
        /// Discovers the filter urls.
        /// 
        private void DiscoverFilterUrls()
        {
            if (this.web == null)
                return;

            this.filterUrls = new List();

            SPSiteDataQuery query = new SPSiteDataQuery();
            query.Query = "PerformancePoint Filter";
            query.ViewFields = "";
            query.Webs = "";

            DataTable dt = this.web.GetSiteData(query);

            foreach (DataRow row in dt.Rows)
            {
                // we want the path to the item itself
                string url = row["FileRef"].ToString();
                url = url.Substring(url.IndexOf('#') + 1); // These are site collection relative urls

                this.filterUrls.Add(url);
            }
        }

        /// 
        /// Determines whether [is filter encoded as set] [the specified filter name].
        /// 
        /// Name of the filter.
        /// 
        ///   true if [is filter encoded as set] [the specified filter name]; otherwise, false.
        /// 
        /// Charts haven't been fully configured - check ChartParametersEncodedAsSet in web.config
        private bool IsFilterEncodedAsSet(string filterName)
        {
            bool isSet = false;
            string filtersEncodedAsSet = ConfigurationManager.AppSettings["ChartParametersEncodedAsSet"];
            if (string.IsNullOrEmpty(filtersEncodedAsSet))
                throw new ArgumentNullException("Charts haven't been fully configured - check ChartParametersEncodedAsSet in web.config");

            string[] filtersEncodedAsSetArray = filtersEncodedAsSet.Split(';');

            foreach (string s in filtersEncodedAsSetArray)
                if (s == filterName)
                    isSet = true;

            return isSet;
        }
    }
}

SPSite, FileNotFoundException and the Server Object Model in Console Applications and PowerShell Scripts

2013-04-19T21:11:00.000+01:00

For a beginner SharePoint developer, there can be a fair amount of confusion around the seemingly trivial task of building a C# Console Application to connect to a SharePoint site and to learn the object model. You merely include a reference to the Microsoft.SharePoint.dll assembly, instantiate an object, passing in your site URL and you're off. Right? Well, hopefully, but you might also get the oft-thrown 'FileNotFoundException' when trying this out for the first time (or even, the first time in a while if you've been somewhat absent from doing this, or have been rolling around in the delights of PowerShell too long).

First of all you need to ensure your Visual Studio Console Application project is set to build to x64 (or AnyCPU) - this is because your application must be able to load the 64-bit Microsoft.SharePoint.dll assembly (this is the first, legit reason for a FileNotFoundException, it literally can't find a (64 bit version of a) file.

(Hint: On CodePlex is there's an amazing toolkit known as CKS Dev (Community Kit for SharePoint) which includes, amongst many other very productive features, a 'SharePoint Console App' project template, which streamlines most of this project setup process for you. Definitely something to install if you do a lot of SharePoint Development of any kind). As of time of writing, the Project Templates have yet to be imported in the Visual Studio 2012 but still work grand in the Visual Studio 2010 version).

Next the problem usually is permissions - the security context of your console application (literally, the account you're logged in as) must have access to the SharePoint environment, and more specifically, the configuration database of your environment.

Lastly, the SharePoint site you're trying to connect to MUST be local to the server on which you're running the console application. And it does not matter which Alternate Access Mapping URL you try to connect to.

And this last reason is the main reason for my article. Why must the site be local?

The reason is fairly simple. If you have followed other articles on the web to create Console (or Windows Forms, or Web Services, or anything .NET that's not a SharePoint project) applications that use the Microsoft.SharePoint.dll, you're using what's known as the Server Object Model. You probably already know this, or have read that you're doing this. You probably are also at least somewhat aware that there is also a Client Object Model out there. And a JavaScript Object Model.

So what's with this Server Object Model, and why must code that uses it run solely on the server that hosts SharePoint? Also, when you do use this, have you noticed a significant delay when you first open that SPSite connection?

The answer lies in the SPSite object. It has many constructors (6 in total, currently as of SharePoint 2013), but they all essentially do the same thing. Internally, your request to 'open' a SharePoint site is passed right down to SharePoint's internal data connection layer (a native DLL with the obscure name 'owssvr.dll'), which knows some very specific information about the system that is running your console application. This file can only be found on environments which have had SharePoint installed on them (another reason for the famous FileNotFoundException? Perhaps, but there is also a COMException that can be raised for when this dll can't be found)

Whichever constructor you choose to use, the SharePoint internal code 'asks' the local server where the configuration database is. It needs to do this because it has to ask it in which content database the SharePoint Site Collection with URL http://xyz or with Guid abcdef-... exists.

Therefore, if you try to write a simple console application, and pass in the the URL to a SharePoint site that it NOT on your development server, you are basically asking SharePoint to find a Site that is registered on your local server.

This story is exactly the same if you try to run a PowerShell script against a SharePoint Site URL that is not a part of the server's SharePoint Farm (there is an exception to this, namely for Office 365 hosted SharePoint Online).

If you do actually intend to run your application on another server, then make sure the site collection URL is a parameter for your application somehow.

If you need to interact with SharePoint and run a program that will NOT be running on the SharePoint server itself, then you will need to learn either the Managed Client Object Model, or one of the many Web Services that are now available (Classic (asmx) Web Services reference, ListData.svc REST endpoint, SharePoint 2013 REST _api [awesome, check this one out]).

Notice that I didn't mention the JavaScript Object Model in that list. There is a reason for this also. I might go into this in detail in another article, for now it's similar to the Server Object Model problem - the SharePoint JavaScript Libraries are loaded only from SharePoint Sites, and can only run within pages that are hosted in the SharePoint site, as they make calls to internal web services that exist on the same SharePoint Site that is serving the page the code is running on. Confusing? I'll try to explain in another article by showing you what happens when you try to include SP.js outside of SharePoint sometime.

But for now, I hope that clears a few things up for new developers.

SharePoint WebPart with Definable or Dynamic Filter Connections

2013-04-19T09:45:00.003+01:00

Here's a code sample which will give you a web part that will have a property (accessible via the Toolpane) that lets you define a semi-colon separated list of the names of Filter Connection points. You can then use any standard SharePoint (or even PerformancePoint) filters connected to the web part and use them how you wish in the code.

Note that I'm building the connection points via a Property, but you can do this any way you wish at runtime - just ensure you set the logic in the SetConnectionInterface method in the code. In my example, I'm just getting an array of strings (from that Property) but this could really come from anywhere.

Enjoy!

Note:
If you intend to use the web part with PerformancePoint, do note that Filters will not work when you add the 'Apply Filters' button. I will cover this in a later post but basically you don't build a standard web part if you want the full PerformancePoint experience.

  
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.ComponentModel;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.WebPartPages;
using System.Linq;

namespace ConsumerWebPart.SampleWebPart
{
    [ToolboxItemAttribute(false)]
    public class SampleWebPart : Microsoft.SharePoint.WebPartPages.WebPart
    {
        private List providers = new List();

        [WebBrowsable(true),
        WebDisplayName("Filter EndPoints"),
        WebDescription(""),
        Personalizable(PersonalizationScope.Shared),
        Category("Custom Properties"),
        DefaultValue("")]
        public string FilterEndPoints { get; set; }
        
        protected override void Render(HtmlTextWriter writer)
        {
            string str = "";

            foreach (IFilterValues provider in this.providers)
            {
                if (provider != null)
                {
                    string prop = provider.ParameterName;
                    ReadOnlyCollection values = provider.ParameterValues;

                    if (prop != null && values != null)
                    {
                        str += SPEncode.HtmlEncode(prop) + "=";

                        foreach (string v in values)
                        {
                            if (!string.IsNullOrEmpty(v))
                                str += v.Replace("&", "%26");

                            str += "&";
                        }
                    }
                }
            }

            writer.Write(str);
        }

        [ConnectionConsumer("Filter Values", "IFilterValues", AllowsMultipleConnections = true)]
        public void SetConnectionInterface(IFilterValues provider)
        {
            this.providers.Add(provider);
            if (provider != null)
            {
                List l = new List();

                foreach (string parm in this.GetParameters())
                {
                    l.Add(new ConsumerParameter(parm, 
                        ConsumerParameterCapabilities.SupportsMultipleValues 
                        | ConsumerParameterCapabilities.SupportsAllValue));
                }

                provider.SetConsumerParameters(new ReadOnlyCollection(l));
            }
        }

        private List GetParameters()
        {
            List parmList = new List();
            string[] parms = this.FilterEndPoints.Split(';');
            if (parms.Length > 0)
                parmList = parms.ToList();

            return parmList;
        }
    }
}

Unable to load first class Dao provider type - PerformancePoint Services error code 10201

2013-03-21T15:50:00.002+00:00

If you're doing development against PerformancePoint Services API, whether in a custom ASP.NET site, a Console Application, make sure you have the Bpm configSection within your web.config (or App.config).

You want to add the following configSection to your config file:

  <configSections>
    <sectionGroup name="Bpm">
      <section name="FCODaoProviders" type="System.Configuration.DictionarySectionHandler" />
    </sectionGroup>
  </configSections>

And you also want to include this under the root element of your config file, to let your application know which Dao providers to load for the various objects PerformancePoint can handle:

  <Bpm>
    <FCODaoProviders>
      <add key="DashboardSPDao" value="Microsoft.PerformancePoint.Scorecards.Store.Dao.DashboardSPDao, Microsoft.PerformancePoint.Scorecards.Store, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <add key="DataSourceSPDao" value="Microsoft.PerformancePoint.Scorecards.Store.Dao.DataSourceSPDao, Microsoft.PerformancePoint.Scorecards.Store, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <add key="FilterSPDao" value="Microsoft.PerformancePoint.Scorecards.Store.Dao.FilterSPDao, Microsoft.PerformancePoint.Scorecards.Store, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <add key="IndicatorSPDao" value="Microsoft.PerformancePoint.Scorecards.Store.Dao.IndicatorSPDao, Microsoft.PerformancePoint.Scorecards.Store, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <add key="KpiSPDao" value="Microsoft.PerformancePoint.Scorecards.Store.Dao.KpiSPDao, Microsoft.PerformancePoint.Scorecards.Store, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <add key="ReportViewSPDao" value="Microsoft.PerformancePoint.Scorecards.Store.Dao.ReportViewSPDao, Microsoft.PerformancePoint.Scorecards.Store, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <add key="ScorecardSPDao" value="Microsoft.PerformancePoint.Scorecards.Store.Dao.ScorecardSPDao, Microsoft.PerformancePoint.Scorecards.Store, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
    </FCODaoProviders>
  </Bpm>

It probably goes without saying, but if you're running this contextless of SharePoint you'll need to fake your HttpContext and point it to instances of SPWeb and SPSite (plenty of tutorials out on the web to do this). Oh, and with the rest of SharePoint code, it can only run on a SharePoint server. There is no client API for PerformancePoint in SharePoint 2010 and I doubt there is one for 2013. If you need you can create a service proxy that runs in SharePoint and gets the data you need.

SharePoint 2010 Server Search Only Crawling Top Level Site

2013-02-21T15:21:00.001+00:00

This one cost me three evenings, and turned out to be a silly little thing, hope it can help someone else.

The scenario:

One web application has one site collection. Only pages in the top level site are being indexed by the crawler. These pages happen to be ones linked by the homepage. Another web application with a site collection and site hierarchy is able to be fully crawled. When I added a static link to a sub site, that sub site's homepage (and other pages it linked to) were being crawled OK, but no other sub sites. No SharePoint list items or documents in document libraries were being indexed in any site (even the top level site).

This was a UAT environment, and our live environment, which appeared to be configured identically, did not have this issue - the entire site collection on live was able to be crawled without issue.

Here's what I checked:

Web App URL was set in the Content Source
Content Source was set as SharePoint Sites
Content Source was set to crawl entire web application
Crawler Account had Full Read on User Policy for the web app
Same behaviour when setting the Crawler Account to a site collection admin account
Same behaviour when crawling any AAM URL for the web app
Was able to log in as any set crawler account and browse the full site
There were no errors in the Crawl Log, only the 6 successes
There were no errors reported in ULS, even when bumped to Verbose
When using Fiddler as a reserve proxy, there were no errors reporting as the crawler happily crawled the 6 pages it could see
Deleting and re-creating the Search Service Application from scratch had no effect
Removing all Scopes and Crawl Rules had no effect

What was the problem?

Missing 'MicrosoftSharePointTeamServices' header in the web application configuration in IIS, as I eventually found in a hint from this MSDN forum post (they are useful sometimes!):

http://social.technet.microsoft.com/forums/en-AU/sharepointadminprevious/thread/6fa317a5-9d2d-41a7-90f4-118050cf82dc

It turns out this header is required by the SharePoint crawler to ensure that the crawled site is indeed a SharePoint site and it can use the standard SharePoint APIs to discover the site's content. If it can't see this, the crawler treats the site as a standard static HTML web site and follows links to discover content. That is why I could only see a handful of pages that were linked from the homepage in the crawl log.

I was able to prove this first by checking the response headers from hitting both the UAT and live environments and checking the headers - when I noticed the the MicrosoftSharePointTeamServices response header missing from the UAT environment, I knew where to start looking.

If you come across this issue, beware that there are several places in an ASP.NET web site where you can control/alter the HTTP Response headers - you can do this in a custom Control (ASCX or CLR type style), in a HTTP Module or, as was the case here, in the application configuration (done in IIS, but can also be done in the web.config). Do also ensure when you manually recreate this you set the version number to the correct version of your SharePoint farm. Subsequent updates to your environment should keep this value up to date. (Actually, I'm unsure if the PSConfig wizard will update this header if it has been removed from a web app...).

Why was this removed?

Security (I guess, someone else did it but has since left the company).

Here's a link to a blog post as to why it's good security practice to remove these headers on public facing websites: http://www.marc-lognoul.me/itblog-en/post/2012/12/05/SharePoint-Removing-HTTP-Headers-for-Security-Reasons.aspx

But do beware, if you choose to follow these practices, ensure you have a web application available which could just be internally accessable but lets search work properly!

ASP.NET Modules - reading InputStream with StreamReader

2013-02-14T09:23:00.000+00:00

If, like me, if you've gotten into habit of wrapping most things that implement IDisposable in a 'using' statement, then you'll be wondering why the hell you can't read from the Requests's InputStream property using a StreamReader without your request pipeline breaking.

Turns out, that you mustn't dispose of the StreamReader immediately, as when you do this it will implicitly dispose of your InputStream also.

So, declare your StreamReader as a private member of your Module class, and only explicitly Dispose of it within the pre-canned Dispose method in the Module class.

Like this:

  public class LoggingModule : IHttpModule
    {
        private StreamReader reader; // Declare the StreamReader here

        public void Dispose()
        {
            if (this.reader != null)  // Dispose of it here
                this.reader.Dispose();  
        }

        public void Init(HttpApplication context)
        {
          
            context.LogRequest += new EventHandler(context_LogRequest);
        }

        void context_LogRequest(object sender, EventArgs e)
        {
            // DO NOT DISPOSE OF IT HERE!
            // It'll can your InputStream object if you do
            this.reader = new StreamReader(HttpContext.Current.Request.InputStream);

            string s = reader.ReadToEnd();

            //Do some funky stuff with the text content of the input stream
        }      
    }

Goes without saying, remember to use BinaryReader if you're not reading plain text in the input stream (in this case, I'm getting the payload of a POST request).

Unable to resolve NTLM or Windows users in People Picker in Central Admin

2012-12-20T08:54:00.001+00:00

This totally drove me round the bend.

If you're in Central Administration and you can resolve FBA accounts find but not NTLM, then check to make sure you're on the correct Alternate Access Mapping for the site.

You might be using http://centraladmin.mydomain.local:12345 and it may not work, until you access Central Admin via http://centraladmin:12345.

Also, if you have a Claims-aware web application with both FBA and NTLM memberships (extended or not) and you have broken the configuration for FBA, this may also break NTLM resolution of names. Make sure you have the Membership provider delcared properly in Central Admin, the Secure Token Service and the target web application.

SharePoint 2013 REST API in iOS

2012-12-13T19:07:00.001+00:00

This post and the included code is the result of a couple of weeks of confusion, hard work and a tonne of research and collaboration between myself and Becky Isserman. There is very little documentation out there on how to do this so we hope that some people will get some use out of this.

TL:DR - show me da code: https://github.com/jimmywim/SPRestAPI

I've written a proper usage guide to the API too, available here: https://github.com/jimmywim/SPRestAPI/wiki/Usage

All of this relates to the Office 365 offering of SharePoint Online, not the on-premises SharePoint Server 2013 (yet). The methods used here aren't (I think) documented and things are subject to change, so I'll try to keep the code up to date for those downloading this at a later date.

The basic task of using any sort of API with SharePoint is authentication. Getting SharePoint to know who you are and for you (the client software) to remember who you are is made easy with the Microsoft provided APIs (Managed and JavaScript Client Object Models), but there is very little out there for anything else. With the release of SharePoint 2013 and the App Model, there has been talk (that I've heard) that makes development for SharePoint using iOS, PHP, Ruby, in fact anything, possible. For iOS in particular, we haven't seen much yet. So we decided to figure it out.

In the .NET world, Wictor Wilen wrote this post on actively authenticating to Office 365. His code demonstrates the steps performed using a helper class he wrote that handles the authentication and the cookie storage needed to remain authenticated. At the heart of his code is some Windows Identity Foundation classes that talks to the SharePoint Secure Store. To replicate what his code does for iOS, I had to use Fiddler Web Debugger to identity what the app was talking to and what messages it was sending.

As he explains in his blog (and as I've seen with Fiddler), there are 3 basic steps to authentication:

Pass the username, password and intended site collection to the Secure Token Service exposed by Office 365
Receive a secure token response from the STS, and pass it to your site's login page.
The response from your login page will redirect to your site's home page, and also include 2 cookies needed to keep you logged in.

The first step is performed using WIF code, and essentially authors a SOAP envelope with your authentication data included. The response from this is packaged into a regular Web Request and sent to your site's login page using standard .NET APIs. The cookies from this are then stored and added to each subsequent request to your SharePoint site to ensure you're kept logged in. If you wish to 'log out', you only need to discard the cookies (and possibly make a request to SignOut.aspx, incase there is any Session information stored on the server that needs to be cleared).

So, let's describe how I've implemented the above concepts into a re-usable framework for iOS. Hopefully I've made this as simple as possible, though at this stage the code can only issue GET requests, and therefore can't add new data to a site.

I should probably point out that I'm no expert programmer in Objective C, having come from a C# background of nearly 8 years experience. There are parts of the code I don't fully understand (in particular, the delegates) and parts that are just syntactically wrong or could be done better. I'm very open to suggestions on how to improve parts, even if just for widening my own understanding of the language.

First we need to authenticate. I do this using a class called SPClaimsHelper.

    NSString *site = siteUrlField.text;
    NSString *username = usernameField.text;
    NSString *password = passwordField.text;
    
    SPClaimsHelper *spClaims = [[SPClaimsHelper alloc] initWithUsernamePasswordSite:username password:password site:site];
    [spClaims setDelegate:(id)self];
    [spClaims GetTokens];

The call to GetTokens initiates the authentication process to log into SharePoint and retrieve your cookies. This class issues a delegate when this is completed to let your application proceed as 'logged in'.

- (void)tokenDelegate: (SPClaimsToken *)tokenClass didReceiveToken: (int)count
{
    NSLog(@"Tokens received");
    MasterViewController *masterVC = [[MasterViewController alloc] init];
    [self presentViewController:masterVC animated:TRUE completion:nil];
}

This code above simple logs that the tokens have been received and loads the next ViewController.

Once we're logged in, we can then issue queries:

    SPRESTQuery *titleQuery = [[SPRESTQuery alloc] initWithUrlRequestId:@"http://mycompany.sharepoint.com/_api/web/Title" id:@"SiteTitle"];
    [titleQuery setDelegate:(id)self];
    [titleQuery executeQuery];

At this stage of development, you'll see I've not implemented 'remembering' the site collection URL, so the request currently has to include this. Hopefully someone can do a more efficient implementation when using this code such that the site collection URL remains defined once and re-used for the queries.

An interesting point to note here is the 'id' parameter of the SPRESTQuery's init method. Here I pass in a string with which I can identify which request has completed within the response's delegate method.

Here's an example of the delegate method handling this request (plus my shoddy idea of how delegates are structured, but hey - it works):

-(void)SPREST:(id)SPREST didCompleteQueryWithRequestId:(SMXMLDocument *)result requestId:(NSString *)requestId{
    
    if (requestId == @"SiteTitle")
    {
        SMXMLElement *bodyElement = result.root;
        NSString *titleText = [bodyElement value];
        self.navigationItem.title = titleText;
        webtitle = titleText;
    }
    [self.tableView reloadData];
}

When we issue more requests from within the same ViewController (or other class) that has the SPRESTQuery's delegate, we can use the requestId to identify which request has completed.

As you can see, the response XML is returned as an SMXMLDocument object, which comes thanks to these guys, for making an awesomely simple XML parser: https://github.com/nfarina/xmldocument

And that's all there is to it!

Finally, here's the link to the GitHub repository where I'll be maintaining the code.

https://github.com/jimmywim/SPRestAPI

Cheers!

SharePoint Conference 2012

2012-11-25T13:39:00.002+00:00

So this year I was given the opportunity to go to the Microsoft SharePoint Conference at The Mandalay Bay Convention Center in Las Vegas this year, and damn was it an experience! After a week of being back in the UK I thought I'd just jot down a few thoughts on the conference overall, as well as some key messages I took away from the event.

EDIT: This turned out way longer and less organised than expected. The conference, however, passed way quicker and was far more organised than this :)

Mandalay Bay Hotel overlooking the Convention Center

We're all headed to the big blue!

MS were really pushing Cloud stuff big time. Most session demos were hosted in Office 365, and given the problems with the wireless connectivity, most of these demos seemed to work really well! They were keen to show off the performance of Office 365 too in the keynote, where the demo environment was apparently hosted in datacenters in the Netherlands (some 8000km away) with sub-1 second page loads every time (though how they forced their environment not to use a geographically closer one I don't know, and something they didn't allude to either). New technology demos (of the App Model for SharePoint and Office) were all using Azure-hosted solutions too.

It was emphasized (although only a couple of times) that the 'classic model' of SharePoint development (now known as 'full-trust solutions') are still fully supported 'for the time being', though it's strongly suggested to consider the new App Model (starting with SharePoint Hosted) when scoping out new development requirements for projects. It was also made 'official' that the Sandbox environment is officially deprecated, though Sandbox solutions will still work, they probably won't at all in vNext.

Opportunity awaits!

Going on from the App Model for Office and SharePoint, they were keen to demonstrate that it's now possible to develop small apps for the two that can be available for purchase from the App Stores for both products, which present opportunities to monetize on add-ons that can be available to potentially millions of Office users across the world as everyone upgrades to Office 2013 (although I reckon it'll probably take until the vNext release of Office to get to serious numbers of potential customers).

Simplicity wins the crowd

Throughout the week I saw examples of the crowd going 'nuts' (from minor applauses to raucous cheering) for the most trivial of updates to the user experience, from things like dragging & dropping directly into document libraries in the browser, to the ability to paste 'raw text' from formatted documents such as Word into Publishing page text fields. It seems true that no matter what huge architectural changes you make to the platform, people still love the smaller changes that the end users actually notice. Good to see Microsoft making these changes though.

Everything works much better in other browsers now, too. Even 'Napa', the browser-based development environment for SharePoint-Hosted apps works perfectly in Chrome. Think of a trimmed-down Visual Studio with a full code editor (complete with IntelliSense and syntax checking), but without a Design view, and that is Napa. Very impressive, and even moreso by the fact it works in Chrome.

SharePoint Designer? What SharePoint Designer?

Although I attended maybe around a dozen of sessions throughout the week, I don't think I even heard SPD being mentioned once. We all know (or should've by now) that the Design View has gone (making some people kinda pissed, to say the least) one thing I did notice is that according to the MSDN Documentation, there are some deprecated API sets, both of which I believe SPD uses almost exlusively. Does this mean huge changes to SPD vNext, or maybe it'll be disappearing altogether!

One of the coolest things to come to SharePoint 2013 for designers is the ability to author their designs using whatever HTML design package they fancy (they demonstrated Dreamweaver), and to upload their designs directly into SharePoint (using something called the Design Manager) and have it generate the masterpage for the site. This might be another downfall for SharePoint Designer, who knows. I didn't see any sessions on creating Page Layouts though (I only saw one WCM session but it didn't touch on this), so I've yet to see how these fall into the Design Manager in SP2013.

Yammer

I'm beginning to hate that word. Purely for the lack of direction that Microsoft seem to be taking with this seemingly rushed aquisition. They've sweetened the deal for some, by giving all new Office 365 customers the full (normally paid-for) Yammer service as part of the bundle. Integration between the two services seems very hack-and-slash, with the ability to 'link' through to SharePoint from Yammer, and to roll-up content from Yammer into SharePoint, but that's about it. Yammer got a decent amount of coverage in the Keynote, but everything that was shown off about Yammer was already a feature in SharePoint's Social features, but the two are completely separate. I really hope that either Yammer is fully pulled into SharePoint or the Social features of SharePoint get dropped, as this is one area of Microsoft where it seems there is no clear vision whatsoever on where things are going. If I was a key decision maker I'd be pretty frustrated at this.

The Keynote was quite well presented, felt like some
huge concert from the front row

Freebies? What Freebies?

Considering the tickets for this conference were verging on $2,000 each, one thing that was hushly mentioned throughout the week was the fact that a few weeks previous, attendees to the Build conference received a Surface with Windows RT and a Nokia Lumia 920, whereas we got nothing of the sort. I do suppose you have to remember that this conference is not primarily a developer conference, but you'd have though that if they were pushing Cloud so much, there'd be some kind of discount or vouchers for Azure and Office 365 (longer than the standard 90 days that currently anyone can get). There was occasions though, where you thought that you (or your company) has paid nearly $2,000 to be advertised to for four days. It's a cleanly good job, however, that were the usual community speakers, recognized faces, and networking opportunities that helped make the conference an awesome all-round experience.

In the Expo Hall there was an area devoted to Microsoft Products we all know and use daily, such as Visual Studio, Project, a stand for web stuff, and others. Manning these stands were folks from the Product Groups and communities who were keen to talk about new stuff and give demos. That was pretty neat for anyone who didn't get a full pass and an Exhibit-Hall only one.

Entertainment

Unfortunately due to heavy jetlag I was unable to make it out to the Monday night parties, but the general message from others was that the Avepoint Red Party seemed to be the best (closely followed by Axceler's party) - though I did nip for a bit out with a few folks to the Vesper Cocktail bar at The Cosmopolitan (a very swanky place indeed, though at the time I had no idea how prestigious a cocktail bar it is!).

Jon Bon Jovi and The Kings of Suburbia played a pretty decent set on the Tuesday night event at the Mandalay Bay beach resort outside the hotel, I think that the gig had just the right amount of 'cheese' that you could hand to 10,000 IT folks.

Overall

Overall the conference was indeed worth it. A huge advert at times, but enough of the usual suspects to make up for it. Here's the biggest messages:

Cloud is better
Full-trust solutions out, Azure In
Social is still vision-less but still talked about hell of a lot
Andrew Clark knows his cocktails
It is indeed possible to feed 10,000 folk without massive queues, and provide real table service!
Next time I do something like this, head out a few days earlier to recover from jetlag, and to see some other sights the place has to offer!

Reporting Web Service Proxy does not exist in the farm - SharePoint 2013 Preview and SQL Server Reporting Services

2012-07-19T15:45:00.002+01:00

If you get the above error when trying to create a SQL Server Reporting Service Service Application with SharePoint Server 2013 Preview, you will need to register the RS Service Proxy via powershell..

Follow these steps to do this:

SharePoint 2010 Management Shell with administrator privileges.Right click the icon and click, "Run As Administrator". Run the following three cmdlets from the shell:
- Install-SPRSService
- Install-SPRSServiceProxy
- Get-SPServiceInstance -all |where {$_.TypeName -like "SQL Server Reporting*"} | Start-SPServiceInstance
Verify the SQL Server Reporting Services Service shows status as “Started” on the page: SharePoint 2010 Central Administration -> "Application Management" -> "Manage Services on Server"

Now attempt to create a RS Service Application, it should complete without fail.

This information was found on the SQL Server 2012 Reporting Services Tips, Tricks, and Troubleshooting page on TechNet.

SharePoint Server 2013 Preview - Testing BI on SQL Server 2012? You need CTP3!

2012-07-18T14:23:00.001+01:00

If you have installed SQL Server 2012 and wish to test out the Business Intelligence features (particularly SSRS in SharePoint 2013 Preview) you will need to install SQL Server 2012 SP1 CTP3 - this release is designed solely for testing out the Business Intelligence capabilities of SharePoint Server 2013 Preview.

You can download the installers from the Microsoft Download Centre here:
http://www.microsoft.com/en-us/download/details.aspx?id=30375

Do note that this page expressly states that this release of SQL Server is for testing BI in SP2013, and not as a regular service pack / patch.

If you don't use this edition of SQL Server 2012 you may find that you will be unable to create a Reporting Services Service Application in SharePoint 2013. I believe this is because SQL Server 2012 has installed the RS files required for SharePoint Server 2010 (everything in the 14 Hive), and of course SharePoint 2013 Preview has everything it needs in the 15 Hive for normal use.

You can download the ISO image, or for a smaller download size, retrieve the EXE and associated BOX file (the install requires both, and run the EXE file once you've got both).

Connecting to Analysis Services on SQL Server 2012 from PerformancePoint on SharePoint 2013 Preview

2012-07-18T13:36:00.002+01:00

You might notice in PerformancePoint Dashboard Designer that when you create an Analysis Services Data Source, typing in a server name throws no error but the Database dropdown box never populates.

Look to the event logs and you might find this error shown shortly after loading Dashboard Designer:

Unable to load custom data source provider type: Microsoft.PerformancePoint.Scorecards.DataSourceProviders.AdomdDataSourceProvider, Microsoft.PerformancePoint.Scorecards.DataSourceProviders.Standard, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.AnalysisServices.AdomdClient, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.AnalysisServices.AdomdClient, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'
at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type)
at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName)
at System.Type.GetType(String typeName, Boolean throwOnError)
at Microsoft.PerformancePoint.Scorecards.Server.PmServer.InitializeCustomDataSourceProviders()

PerformancePoint Services error code 10107.

As you can see, PerformancePoint here isn't using ADOMD.NET 11, the SQL Server 2012 version.

You need to find the version 10 of ADOMD.NET installer which comes with the SQL Server 2008 R2 Feature Pack from the Microsoft Download Centre. Install this, perform an IIS Reset then open PeformancePoint again to see the Data Source editor working fine once again.

Direct Link for ADOMD.NET10 for x64

Microsoft Download Centre page for SQL Server 2008 R2 Feature Pack

If You Do This, I Hate You

2012-06-08T18:19:00.002+01:00

I'll come clean. I know a lot of what I know because I know how to Google/Bing for answers. Yes, other people have taken the time to answer other's questions, I just know how to get them.

But there's a certain kind of person that hampers my efforts in finding out other people's answers to my questions. If you're this kind of person - please change your habits lest I hate you forever.

These people are found in the public fora of StackExchange and the MSDN forums. Not so much the StackExchange fora as they're moderated by the community and so bitchslap these offenders anyway. MSDN forums are not really moderated at all (other than removing sweary posts), have no 'negative' voting system and are littered with the following annoying habits:

'Answering' a post with just the words 'I have this problem too'
'Answering' a post with just a link to a blog that now returns a 404, with no explanation as to what was done to resolve the issue
'Answering' a post with just the words 'Thanks, I got it working' with no indication of what was done to resolve their issue

Seriously folks - by 'taking' from the community by just asking for free answers to questions, you can 'give' back by being a bit more verbose in your answers. Part of what makes a community great is being able to find answers to any question thanks to those in the community answering questions fully in the first place.

SSAS 2008 R2 Processing Performance Tips

2012-05-04T23:01:00.002+01:00

I haven't posted on this for a while as I've been neck-deep in a fairly decent sized Business Intelligence project in SQL Server Analysis Services 2008 R2, but have subsequently learnt an enormous amount with regards to performance. So I thought I'd share a list of the biggest things I've learnt from various places (mostly Books Online and TechNet) to help make things that bit quicker when you have a large OLAP cube to process.

Reduce the number of attributes where ever possible in your dimensions
This is particularly important if you have Intermediate Dimensions used for Many to Many relationships. Because these tables can grow enormous relative to the size of the other dimensions, you want to minimize the number of columns that SSAS needs to worry about. If you are using Intermediate Dimensions, remove all but the keys used in the joins, and don't try to join to other tables. The Intermediate Dimension shouldn't be visible to the end user anyway (use Perspectives).

Remove unnecessary attributes from your dimensions where possible.

Yes, I've listed this twice, as it really does help performance. It can also reduce the final footprint of the database on the filesystem!

Script out the process job.

Use two separate jobs, one to issue a ProcessData command and the other to do ProcessIndexes. By default, a ProcessFull is issued (unless you do an Update), which does both of these, but some other (seemingly unnecessary stuff) and adds about 10% to the overall processing time. If you try to do this with a single job with a Parallel task it'll probably error out (trying to process indexes on data that doesn't exist yet).

As well as the above, put the two jobs into a SQL Job as two separate steps.
This lets you execute these on the server and log off your session, leaving the server precious resource to do its thing.

Learn XMLA
You'll be doing this as you do the above two steps anyway. In SQL Server Management Studio open up the Template Explorer (from the View menu), switch to Analysis Services (by clicking the Cube at the top of the panel) and play with the different XMLA templates available (careful where you execute the DROP command ;) )

If at all possible, have the source relational database on separate physical volumes to where the analysis services databases will end up.

Not only will this help processing performance, but if your SQL Database instance is used for other things, queries against your cubes shouldn't aversely affect the performance of that SQL instance. Even better, have it on a separate server and free up those resources! Just make sure you have a VERY good network connection between the two (to speed up reads. Try and get at least 50-100MB/sec transfer rates between the boxes).

Add more RAM

Lots of RAM. Max out the box. Seriously. As the process happens, it queries SQL Server for the relational data, and this works faster the more RAM it has (buffers fill faster than they can be flushed, it seems), and Analysis Services will grind to a halt if it doesn't have enough RAM. An easy way to spot if SSAS is low on memory during a process is to spin up Resource Monitor from Task Manager (under Performance Tab), go to the Disk tab, and see what files are currently being requested. If you see minimal CPU usage and many .khstore files being trickled (at 300kb/sec) off disks, SSAS doesn't have enough RAM (it's doing what's known as multipass processing, which in my experience is very, very slow - we've seen times go from 12 hours down to 90mins just because we upped a box form 32GB of RAM to 64GB).

Make sure the Lower Memory Limit is set properly

And by properly, keep it around 15-20 below what the Max Limit is set. When SSAS runs after a restart it needs to allocate memory as it needs it, I'm somewhat almost convinced things run faster if it's already preallocated itself everything when it first starts up. That might just be me though. Just make sure it has enough RAM regardless :P

Restart the SSAS Service before you process

You can either do this or just flush the cache of everything in the instance before you kick off the Process. What you want is for SSAS to have as much RAM as possible for the Process tasks as it can, and for that precious memory not to be taken up with useless* cached queries and aggregations it has hogging up all that juicy memory.

Have a separate physical box just for processing changes...... and backup/restore the newly processed cubes onto your staging/production server. This alleviates performance issues on the live cubes to keep users happy. Also this'll prevent their horrendously complex queries swallowing up the RAM you need to reduce the chance of your Process going into multipass mode. You'll need a fat wallet for this though. But you're on a BI project, so you probably knew this fact already, right? :)

*everything out of hours is useless, right? And you are doing processing out of hours, right? ;)

This can probably go on and on, but these are the big ones that jumped out at me. I'll probably add a 'Part Two' at some point with more tips when they come to mind.

Toodle-oo!

What The Hell Is A SharePoint Site Collection?

2012-02-13T19:51:00.001+00:00

Here's another introductory post about something that I always see confusion over when new users to SharePoint hear these terms - Site Collection and Web site. What the hell is the difference between the two?

Here's my TL;DR answer (followed by a lengthy discussion):

SITE COLLECTIONS DO NOT STORE CONTENT

A site collection is just a container for a collection of web sites.

So why do we have a differentiation between that and a website and what's so special about them?

A site collection groups together websites, and (perhaps most importantly) the security data for these websites. Every piece of 'content' in a website, and even the website itself stores information about who can and cannot access it (any developers reading this - SPWeb, SPList and SPListItem inherit a class called SPSecurableObject which provides the security functionality). Incidentally, each of these items also contains a reference to it's 'parent'.

A List Item must exist in a List, therefore it has a parent, and a List must exist in a site, there it has a parent. A Web Site also has a parent, as you can have nested websites. And here's the interesting part.

To the Site Collection - all the websites within it are in a flat hierarchy (Programmers: SPSite.AllWebs). The 'Parents' of each website are irrelevant to the Site Collection itself - what it does care about is a single website that it denotes as its 'Root Website'. There can only be one RootWeb within a Site Collection. This is also known as a Top-Level site in SharePoint (typically, developers will refer to it as the Root Web).

Now, it's possible to 're-parent' a web site in SharePoint by simply changing it's URL. Let's say we have a site collection at URL: 'http://server/sites/'. If a website 'subsite2' exists at URL 'http://server/sites/subsite1/subsite2' then its parent is 'subsite1'. If we simply changed the URL to 'http://server/sites/subsite2' then its parent is the Root Website of the site collection, which is at 'http://server/sites/'.

So if every website has a parent, what about the Root Website of a site collection? It's a website like any other therefore exposes a Parent, but what does it come back with? Well, URLs are everything when it comes to the hierarchy of a web site. When you ask for the parent, it simply looks for the 'next level up' in the URL. If it reaches the actual URL of the site collection, it will return itself.

So a Site Collection contains a flat hierarchy of websites, whose hierarchy is defined in themselves, and these websites store their own security data. What else?

Well, a Site Collection stores references to a bunch of information critical to any web site. This information includes, but is not limited to:

Web Parts
Users which have access to the website
Themes
Sandboxed Solutions
MasterPages
List Templates

Now each of these sets of information is made accessible via special lists that are only accessible from a site collections root website. These Lists do not exists in the same way that they do in any other website in a site collection, instead the 'list' is dynamically generated under what's known as a virtual folder (_catalogs) on the server. SharePoint provides a familiar List interface for interacting and managing this critical metadata.

Exceptions to the list of information above includes Users, but also Content Types and Site Columns. These objects are handled slightly differently as these objects can be associated to have a web site as a parent. As these objects are tied to the site collection, they are restricted to that site collection and cannot typically be shared between. You can add a user to multiple site collections, but if you add her to one site collection, you need to add her manually to another site collection if she must have access to it. A notable exception to this is the Content Type Hub in SharePoint 2010.

One last point, is that a site collection and all its relevant data, and all the websites that it contains are all stored within a single content database. You can pile as many as you want (up to 250,000!) site collections in a content database, but you cannot split websites across content databases.

So there we have it. A Site Collection is a container for a collection of web sites, with important information that all of the websites use in some way, and a reference to one special website denoted as its Root Web.

SharePoint Development - What to Learn?

2012-02-10T19:26:00.000+00:00

I thought I'd jot down a few things which I believe fresh SharePoint developers need to know when they're confronted with the daunting task of developing something for SharePoint for the first time.

SharePoint development has a massively steep learning curve. It literally takes years to get good at not only developing solutions in SharePoint, but also using the right techniques and tools to develop those solutions. And the reason for this is because the platform itself is so big. There are so many facets to consider when choosing how to architect a solution, as well as the tools available are themselves quite involved. Not only does it take a long time to learn how to develop, it can take just as long, if not even longer, to understand the full capabilities of the tools at hand.

In this post I'm going to list a few key 'areas' I think any first time developer should look into, gain a brief understanding of, and most importantly, be aware of, when getting started with SharePoint. Not only will this make the new developer aware of the scale of the task ahead, but also (hopefully) give some direction as to what technologies they should research as they go into the journey that is SharePoint Development.

I have added various links to pages I think will give you a start in reading about the various areas. Some of these links may be written for earlier versions of SharePoint but the topic may still be relevant in SharePoint 2010. If I haven't included a link for a specific topic... I'm sure you know how to use Google :)

Microsoft SharePoint Foundation

This might sound obvious, but it is vital. If you are going to develop for SharePoint, you need to know SharePoint. And know it well. If you're new to SharePoint and have been given the task of building a solution in it (I feel for you if that's the case, many of us have been there!), you already have a mountain of a task ahead of you. It won't take too long, and there are plenty of resources out there, but you need to gain an understanding of what SharePoint is already capable of, without customisation.

This brief list is a collection of things I believe you need to have a basic understanding of:

How Lists and Libraries work
How Site Collections are related to Web Sites
How Content Types work within Site Collections and web sites
How permissions work within Site Collections
What Web Applications are
How Web Apps are tied into IIS
Know your way around SharePoint Central Administration
What a Service Application is
What a Timer Job is
What a Feature is (and what makes up a Feature)
What Feature Scope is
What a SharePoint Solution Package (.wsp file) is
What an Event/Web/Feature Receiver is (and how they're registered)
What a web template is (and what they consist of)
What a site definition is (and what they consist of)

That list is not exhaustive, but I think it's a brief look at the scale of what makes up a SharePoint environment in terms of what's customisable. Also note, that none of the above necessarily means any C# source code is involved, though quite a few are built up of XML files.

Microsoft SharePoint Server

You what? There's more? Damn right. SharePoint Server is essentially a licensed pack of enterprise-level customisations built on top of SharePoint Foundation. Whilst I'm not going to list here what you should know about SharePoint Server, you should at least have a look around on the Microsoft website for SharePoint to see the differences between the editions of SharePoint, and see what's "available" in terms of feature sets. Each of these has a significant amount of documentation already on what they do, how to set them up, and what they're capable of.

A couple of elements I will suggest that a new developer look at is how the Publishing framework works within SharePoint Server 2010, and Variations. You don't at this stage need to know in-depth of how to create a page layout, for example (unless you're being thrown into a Web Content Management project!), but at least have an awareness of how page layouts work, how they're tied closely into Content Types and the special "Pages" library in a Publishing site. Variations is a method of creating versions of content targeted to specific locales (languages) or devices (mobiles, tablets, etc). This is a slightly complex framework that is not at all customisable, but you should have an awareness of how this works just in case it sounds like a feature that you may need one day (and also know when to avoid it!).

Is this necessary if you only have SharePoint Foundation in your environment? Absolutely - if you want to strike up a cost-benefit analysis to see if it's cheaper to develop and support a small piece of functionality that's already available (and fully supported) in SP Server, or if there are features that will satisfy requirements, and benefit the rest of the business by upgrading your licenses to SharePoint Server.

In short, for this and the previous section - a good SharePoint Developer has a clear understanding of the majority of the capabilities of the platform as it comes.

Microsoft Office 365 SharePoint Online

This is yet another SharePoint offering from Microsoft which provides hosted services. If your environment is hosted in this manner, this will affect the decisions you make in terms of your architect for your solution. There are many differences and restrictions to what's possible for customising SharePoint Online in Office 365 compared to 'on premises' environments, and as a developer, you should read up on what those differences are.

Here's a link on MSDN as an overview of SharePoint Online for the developer.

The Tools - SharePoint Designer

Learning what SharePoint is already capable of is a very steep struggle as it's so expansive a platform. There are a fair number of business cases that it can easily satisfy from just configuring a SharePoint site, for example creating lists, libraries, applying simple branding themes, alerts, etc. SharePoint Designer is a client application that can connect to a SharePoint web site and provide an easy way to quickly create lists, content types, and even simple workflows. You can also do slightly more advanced customisations in terms of modifying Publishing page layouts and web part pages, for example to provide advanced List Views with custom XSL style sheets to display data in any way you want.

As a developer you need to understand that this tool connects directly to a SharePoint site, know that restrictions can be put in place as to what can done in SharePoint Designer, and what is ultimately possible.

Here's a link to an introduction to SPD on the SP365 website.

It's also possible to extend SharePoint Designer - you can add more 'workflow actions' to allow workflow designers in SharePoint Designer to do satisfy more business specific scenarios. This kind of customisation of SPD leads onto the next section...

The Tools - Visual Studio

Visual Studio 2010 is the tool most associated with the developer. The developer is seen as a code hack who lives in VS and swims in C# and XML all day. Whilst this may be true for some, a good developer has a reasonable cause to go to Visual Studio. They want their solution to be easily re-deployable, to be version-controlled, and most likely, the feature set provided with SharePoint Designer and the SharePoint platform itself does not satisfy the original business requirement.

So, what do you need to know about Visual Studio? Hell of a lot, before you even start writing code! There is a good selection of different project and item templates provided with Visual Studio, and they have their shortcomings. The SharePoint community has satisfied many of these shortcomings with the CKS:Dev toolkit available from codeplex. But before diving straight in and getting the template, you need to fully understand the capabilities of the templates already provided, what restrictions you may have if you go straight into a CKS:Dev template - for example if you're in a team environment, other team members may not be able to open your projects if you created it from a CKS dev template!

You also need to understand how Packages and Features are structured within a Solution in Visual Studio, how SharePoint Project Items in Visual Studio can be inserted into Features, how Feature Scope is set up, how to add SafeControl elements to items, how to add extra assemblies into a package (in addition to those generated by a Visual Studio Project).

If you're developing in Visual Studio, or think you may need to do so, then you'll need to understand that will never, ever, EVER deploy to a live environment. You will always develop to a local server. You may need to have a virtual machine with a SharePoint environment set up and running, with Visual Studio also installed, and you develop in that environment. You will also need to understand that what you develop, is tested and debugged in your local environment, but it absolutely must, with no exceptions, be deployed on a test environment (completely separate to your development environment) which closely matches that of the live environment (but again, is completely separate from the live environment).

Already the costs involved here are very high - you need licenses for Visual Studio, Windows Server and SharePoint for your Virtual Machine, you need an environment which can closely match the live environment for testing your solution. As these costs are already quite high (and you've not even spent a day writing code towards your solution yet!), you better have a good knowledge of SharePoint itself, and SharePoint Designer, to justify going to these lengths, and be certain you're not reinventing the wheel, and not redeveloping something SharePoint can already do.

The Technologies - ASP.NET

SharePoint Foundation is a very complex application structure built on top of ASP.NET, which is an application development framework designed to produce web-based systems. The development of ASP.NET is, and has been for the past 8 years, far quicker than that of SharePoint. To give an example, the version number of ASP.NET that SharePoint runs on is ASP.NET 3.5. The most current version of ASP.NET is 4.0. There are quite a lot of very cool features in ASP.NET 4.0 that you cannot take advantage of within SharePoint, as these features are not compatible with SharePoint. We will not see SharePoint use ASP.NET 4.0 until the next version (which may be released next year). At this time, ASP.NET 5 will be under development and may even have a release soon after SharePoint's next release.

The short of that is, if you are coding for SharePoint 2010, ensure everything you do is built towards ASP.NET 3.5.

More of what you need to know about ASP.NET is the basic building blogs, such as master pages, the 'web.config' file, the Page Lifecycle (what events are triggered in code as a page is loaded), caching, etc.

With Visual Studio 2010, there is the Web Application template provided, can you can create and test out simple ASP.NET Web Applications that run on your development environments own debugging web server.

You don't need to have a fantastically in-depth view of ASP.NET, but again, at least have an awareness of what makes up an ASP.NET website and how pages are built.

The Technologies - C#

FINALLY, THE CODEZ! Yup, once you've got an idea of how all the above works, you can finally be let loose on some code. But what to code? And how? Well there are plenty of tutorials for 'simple' projects for getting started with code, but here's what I think a new developer should look at in terms of learning C# for SharePoint Development:

C# Syntax
Object Oriented Programming for C#
.NET Framework fundamentals
Only develop in .NET 3.5 when coding for SharePoint 2010
How to browse the MSDN Class Libraries
The SharePoint Object model
The following classes and how they are linked to SharePoint itself:

That list is nowhere near exhaustive. SharePoint development in C# is probably the largest topic, as there is many, many ways to solve the same problem using a custom coded solution.

You should also be aware of what restrictions you have when development for the 'Sandboxed' User Code environment, available both in SharePoint Foundation, but also the only option when doing custom development for SharePoint Online in Office 365. The Developer Guide for Office 365 is available on MSDN.

That's NOT all folks...

This post has barely scratched the surface of SharePoint development, and I have not covered Client Side Development Techniques or Infopath! However, I think (and hope) it gives people some direction as to what tools and technologies and areas they need to research and do their homework on, to satisfy that oft-asked question... "How do I get started with SharePoint Development?".

Applying CSS Customisations in SharePoint - A Technique

2012-02-05T17:11:00.002+00:00

Having done numerous branding exercises in SharePoint over the past few years, I have had the opportunity to try out various different methods of both loading CSS into your environment, and also the actual writing of the CSS.

I have previous covered methods of loading CSS, and spoke about it in a video, which you can view here: Video - SharePoint Branding with CSS Customisations.

In this post I'm going to show a technique for writing CSS that I've recently came across, that definitely can help to improve both legibility of your CSS files, but also the reusability and flexibility of the classes you customise.

My first couple of branding attempts in SharePoint (back in the 2007 days) were examples of what I'd describe as 'blanket' branding. Each element I wanted to change, I would select in Firebug or Chrome's DOM explorer, find out the CSS that applied whatever was there, and write a line of CSS to change it.

This quickly resulted in a rapidly growing CSS file that would apply a single look and feel across the entire site, and proved very difficult to modify later on.

Here is a method that makes your specific CSS changes much more 'modular', in that all you need to do to apply the specified change is to (somehow) wrap the selected element in a DIV or SPAN with a particular class.

Here's an example of why this would be useful. Let's say you wanted to have two List Views on a page, but you wanted one to have a different title bar colour to the other. Now the title bar is covered by CSS class 'ms-standardheader'. If you apply a style change to this class, it will affect both (and all other) instances of the List View on the page (and all other pages!).

If you were to duck into the HTML Editor for this page, and see how the two ListViews have been added:

What we want to do is to wrap the two list views each inside a DIV container, and apply a different class to each. We'll call one 'blue' and one 'green'.

Now we want to write and deploy some CSS. You can use whatever method you're used to, for this I'm using my favourite method of a DelegateControl to load up an ASCX with CssRegistration. See the video linked above for how to do this.

The CSS I've written for this example looks like this:

As you can see, this is a really straight forward background colour change to each element. I'm using the CSS wrapper that we added to the content above to contain the ms-standardheader class, and applying different style changes to each 'wrapped' element.

Get your CSS into the environment and see the results:

OK, not the most accessible example :) But you can see the premise. I have a usable CSS class that I can use to set the colour of any List View title bar on a page.

You can extend this technique to entire pages, by adding an overall 'wrapper' to the page layout around the content fields, or even the entire site by modifying the master page and adding a 'wrapper' around the content placeholders.

Let me know if you use this technique, or if you have other techniques that you typically use that you'd like to share.