SharePoint (and Project Server) Shenanigans

This is something I came across that is a little more light-hearted than usual.

Taken from Twitter Engineer Angus Croll’s blog.

Once upon a midnight dreary, while I struggled with JQuery,
Sighing softly, weak and weary, troubled by my daunting chore,
While I grappled with weak mapping, suddenly a function wrapping
formed a closure, gently trapping objects that had gone before.

Ah, distinctly I remember, it was while debugging Ember,
As each separate dying member left its host for ever more.
Eagerly I wished the morrow–vainly I had sought to borrow
(From my bookmarked trail of sorrow), APIs from Underscore.

There I sat engaged in guessing the meaning of each cursed expression,
Endless callbacks in procession; nameless functions, nothing more,
This and more I sat divining, strength and spirit fast declining,
Disclose the value we’re assigning! Tell me – tell me, I implore!

via Chris on SharePoint http://spchris.com/2013/05/if-edgar-allan-poe-wrote-javascript/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

You may encounter an exception when running certain SQL Server Reporting Services (SSRS) reports.

The exception message will generally say something along the lines of Operation is not valid due to the current state of the object.

You may encounter this either in reports with a large number of parameters, or in reports where the parameter counts are low but the parameters themselves are multiple choice and have a large number of items selected.

The cause of this is a security fix released by Microsoft under Security Bulletin MS11-100. The fix, among other things, limits the number of keys that ASP.NET applications can parse as part of a request; large numbers of keys could potentially allow a denial of service to occur.

Unfortunately the effect of this is that our large parameter set is blocked, causing the exception and presenting a nasty error to our end users.

Luckily there is a solution to this.

The trick is to add a section to your web.config inside the <appSettings /> section.

<appSettings>
	...
	<add key="aspnet:MaxHttpCollectionKeys" value="5000" />
	...
</appSettings>

The actual value used should reflect the number of keys you believe will be used, but 5000 is a reasonable starting point.

If you are using SSRS in native mode, the web.config file is located within the reporting services installation path, usually C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer.

If you are using SSRS in SharePoint integration mode, the modification needs to be made to the web.config of the application pool where you are running your reports. For this I would recommend that you create a solution that utilises the SPWebConfigModification class as part of a feature receiver, rather than making the changes directly. This will ensure that the change is made across your SharePoint farm simultaneously without the human error that could come from doing the change manually on multiple servers.

Note: In both cases, these modifications either require a restart of the reporting server or in the case of SharePoint a recycle of the Application Pool. This will result in short outages so you will want to schedule this as part of maintenance accordingly.

For more information I would recommend reading the relevant KB article.

via Chris on SharePoint http://spchris.com/2013/05/sql-server-reporting-services-reports-errors-when-large-numbers-of-parameters-are-selected-2/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

When working with SharePoint’s UI, it is often difficult to work out where in the URL structure you are.

You may for instance be working at the root of a site collection, but that itself may be several layers deep.

Take the following example.

You have a site collection for your company, but each team maintains its own site collection under the managed path (with wildcard inclusion) /teams.

Some of the team sites use a template that includes a master page that references an image gallery script. This gallery script has to load images out of a document library local to each team site.

The problem of course is determining the URL to the code and images, when they could be located at /teams/team-a/gallery images or /teams/team-b/gallery images

Of course in a server-side solution this is simple, SharePoint provides the handy shortcut of ~sitecollection. This works both directly in master pages:

<SharePoint:ScriptLink runat="server" Name="~sitecollection/Style Library/js/galleryscript.js" Language="javascript"/>

Or using a custom action within a SharePoint solution, sandboxed or otherwise:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
		ScriptSrc="~sitecollection/Style Library/js/galleryscript.js"
		Location="ScriptLink"
	/>
</Elements>

But how do we achieve the same within the front end itself?

Introducing _spPageContextInfo

The _spPageContextInfo object is a really wonderful little thing. It is added by the SPWebPartManager control, which is included in all of the out of the box master pages (including default.master and system.master) and I really strongly recommend is added to any custom master pages you create.

Because of it’s essentially omnipresent nature it makes using _spPageContextInfo a really simple matter of, well, using it.

It is a small object, containing only a few properties of the page, the site and the site collection it is part of. Here is a JSON representation of what it contains.

{
	alertsEnabled: true,
	allowSilverlightPrompt: "True",
	currentLanguage: 1033,
	pageItemId: 1,
	pageListId: "{6300d68a-4512-49f0-85b9-d3671855e31c}",
	siteServerRelativeUrl: "/teams/team-a",
	userId: 1,
	webLanguage: 1033,
	webServerRelativeUrl: "/teams/team-a/subsite",
	webUIVersion: 4
}

Here’s a brief explanation of the properties in it.

alertsEnabled

This one is simple, is SharePoint’s alerts email notification service enabled for the current web application. This maps to the SPWebApplication.AlertsEnabled property.

allowSilverlightPrompt

Will the user be prompted to download Silverlight if they do not already have it when they attempt to use Silverlight based UI elements. This maps to the SPWebApplication.AllowSilverlightPrompt property.

currentLanguage

This is the current locale being used by the user, if they have not changed it to a custom one, then this maps to the SPWeb.Language property.

pageItemId

This is the ID of the current page’s item within the document library containing it.

pageListId

This is the GUID of the document library containing the current page.

siteServerRelativeUrl

This is the path of the site collection, relative to the web application.

userId

This is the user’s ID for the current site collection.

webLanguage

This is the default language for the current web. This maps to the SPWeb.Language property.

webServerRelativeUrl

This is the path of the web, relative to the web application.

webUIVersion

This is the UI version of the current web, determining if the master page and components in use and available is compatible with SharePoint 2007 (3), SharePoint 2010 (4) or SharePoint 2013 (5)

Note: The actual properties available varies depending upon where you happen to be. For instance the pageItemId and pageListId properties do not exist within system pages, as they do not have IDs and do not live within document libraries.

That’s pretty cool, but how do we use it?

Well, as they are properties we can pretty much use them however we wish. Let’s take a look at a simple way of referencing files in our gallery images document library, for example referencing a logo to use on the homepage.

(function() {

	// The path to the image.
	var imagePath = '/gallery%20images/logo.jpg';

	// The relative URL is usually without the trailing /
	// however if we are on the root site collection then it
	// is simply / on its own and must be handled.
	if (_spPageContextInfo.siteServerRelativeUrl == '/') {
		imagePath = imagePath.substring(1);
	}

	// Build our full image path.
	imagePath = _spPageContextInfo.siteServerRelativeUrl + imagePath;

	// Finally set our image's source to the images path
	$('img#logoImage').attr('src', imagePath);

})();

Of course this is a rather contrived example, and you should probably be using the client side object model (CSOM) to pull items from a document library. However I hope it demonstrates how the object can be used.

A common use I use this for is is actually with the CSOM.

var ctx = new SP.ClientContext(_spPageContextInfo.webServerRelativeUrl);

I do it this way because I have had issues with concurrency when using the get_Current() method in SP.ClientContext when there is other code in use on pages that I do not have control over.

via Chris on SharePoint http://spchris.com/2013/05/managing-path-context-in-sharepoint/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)