Sandboxed code sometimes failing with "Sandboxed code execution request failed"

Nice and short one here (which unfortunately took me a long time to pin down).  I have a simple webpart running in a sandboxed solution.  The webpart has a label and a button, and there is no other code-behind.

Sometimes, when rendering the web part, I get the error:

[SPUserCodeExecutionPipelineFailedException: Sandboxed code execution request failed.]

It's not a nice error but it only appears sometimes.  I'm running on a four-server farm so I assumed it was something to do with the sandboxed code service not running on one of the servers.  However, the service was running on all of them.

It's probably not solved anything (but it's a development environment so I'm not too bothered), but I found a workaround:

1. Go to Central Administration
2. Click on System Settings, and then Manage user solutions
3. In this screen, select "All sandboxed code runs on the same machine as a request".
4. Click OK.

The webpart now works reliably.  I'm assuming one of my servers isn't happy with the sandbox service credentials but I can move on with my life for now.

Creating a printable InfoPath form

I don't like printing.  But inevitably, someone will want to do it somewhere.

We have a list, which uses an InfoPath form for data entering and viewing.  In here, we created a Print view, which is basic black text on white background, and read-only.

However, when trying to print this view, the rest of our SharePoint master page and branding is printed with it, and it doesn't look very professional.  So we needed to create a printable version of this Print view.

Some suggestions online included using jQuery to remove everything BUT the InfoPath form, but this sounded like a messy way of doing things.  Instead, I figured I could just create a new blank page in SharePoint Designer and grab the item ID from the URL.

My first attempt failed.  I tried using a Query String Filter Web Part, but then realised that sending an ID to an InfoPath Web Part doesn't do what you'd think it would do.  It doesn't magically open the item you're referencing with the ID, it simply changes the InfoPath form item ID.  You could use this method for pre-populating an InfoPath form based on parameters in your query string, but not for actually loading an already-existing form.

I figured that you could instead use that ID to filter a List View of your list, and then send that single item to the InfoPath web part.  This would also mean I wouldn't need the Filter Web Part, as a List View has its own Filter and Parameter settings.  So, here's what I did.

1. Using SharePoint Designer, create an ASPX page in your site called PrintForm.aspx.
2. In the ASPX page, add an InfoPath form web part, and configure the web part to use the list you're trying to print items from.  Configure this web part to use the correct Print view that you've already created in InfoPath Designer.
3. Somewhere else on the page, add a Data View, and again configure to use the list you're trying to print items from.  Configure this web part to be hidden or not visible (unless you want to see the list view as well).
4. With the List View web part selected, add a Parameter.  This will be a query string parameter with the name ID, and the Query String Variable of ID as well.  (You can change this to ItemID or something else if you want)
5. Next, add a Filter for the List View web part.  This will get the Field Name ID to equal the parameter you just created, which will be displayed as [ID] or [ItemID] or whatever you chose in the previous step.
6. Finally, Add a Connection from the List View to the InfoPath web part.  You want to Send Row of Data To the InfoPath web part, using the Target Action "Get Form From".  
7. Save and check in the file as appropriate.

Now, if you try to access the URL of this page with an ID added to the end, you will get a nice, basic printable view of your data.  You'll want the URL to look like this:

http://sharepoint/sitename/Pages/PrintForm.aspx?ID=25

What you'll need to do then is add a Print button to the normal Read or Edit view of the InfoPath form, which will send the user to that URL above, with the current item ID after the ID= (in the example above, the item ID is 25).

There's also a little bit of JavaScript you can throw in to your PrintForm.aspx page which will tidy up a few last remnants of the InfoPath web part - namely, the web part name, and the light blue border.  It also presents the user with their browser Print dialog, to save them having to go to File/Print.  It looks like this:

<script src="/scripts/jquery-1.9.1.min.js" type="text/javascript"></script> 
<script type="text/javascript">
  $('.ms-WPHeader').hide();
  $('.ms-WPBorder').css('border', 'none');
  setTimeout(function() {
    window.print();
  }, 500);
</script>

Edit: added a setTimeout before printing, because it was printing a blank page, even though print preview was working correctly.

When was a SharePoint list created? Who created a SharePoint list?

Pretty simple one, this - I was surprised to find I can't easily see a list Created date in the usual SharePoint 2010 interface, so this little PowerShell snippet did the trick.

$spweb = get-spweb -identity http://sharepoint/sitename
$splist = $spweb.lists["List Name"]
$splist | format-table -property created, author

Update: added the "Created By" (author) field as well, so you can see who created the list.

Unable to display this Web Part, only affecting some users, load balancing partially to blame?

This was a particularly strange one.  I can't imagine anyone having the exact same issue as we had this morning, but you never know.

Some users this morning reported the following error:

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

Looking into the SharePoint error logs, I found this:

Error while executing web part: System.NullReferenceException: Object reference not set to an instance of an object.     at Microsoft.Xslt.MethodCollection.ResolveMemberRef(Int32 tokenNum)     at Microsoft.Xslt.MethodCollection.ResolveToken(Int32 token)     at Microsoft.Xslt.MethodCollection.MethodDescription.DeclareDynamicMethod(MethodCollection methodColl)     at Microsoft.Xslt.MethodCollection.CreateDynamicMethods()     at Microsoft.Xslt.MethodCollection.GetMethodInfoInternal(Int32 methodNumber)     at Microsoft.Xslt.MethodCollection.GetMethodInfo(Int32 methodNumber)     at Microsoft.Xslt.STransform.GetCompiledTransform()     at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.LoadXslCompiledTransform(WSSXmlUrlResolver someXmlResolver)     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetXslCompiledTransform()     at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)

Now, some Googling found many references to a Windows Security Update that caused a problem back in July.  However, there was no record of this update being installed on any of the SharePoint servers, and certainly nothing had changed overnight (this problem wasn't occurring yesterday).

The strange thing is, this problem wasn't affecting me, no matter which account I used to try to replicate.  But it was affecting my colleague.  In fact, it was his laptop - when I logged into his laptop with my account, I had the same problem.  His laptop is Windows 7, and my machine is Windows Server 2012 (not the SharePoint server).

I initially thought it was just him, because he was able to fix each individual list view by going into SharePoint Designer, saving the view (without making changes), and the list view worked again.  Until he restarted his laptop, then the problem came back.  Eventually, I had a few emails from other people receiving the same error message.

Very strange indeed, and continued to not affect me.

Some more Googling, and I finally found someone else on TechCenter - Recycling app pool causes webparts to fail - who had the same errors as displayed above, but had occurred before the Security Update, so obviously wasn't caused by that.  They figured out that the application pool used by SharePoint hadn't recycled correctly, so recycling it manually fixed the problem (for a while, although it came back some days later).

As we have two web front ends, using Windows Network Load Balancing, I checked the theory - I accessed one of the offending list views from one web front end, and the error happened.  On the other web front end, the error didn't happen.  Clearly one of my web front ends was broken.

I went into Network Load Balancing, took the broken web front end offline, and recycled the SharePoint application pool.  Problem solved.  Restored NLB, and everything is back to normal again.

But what's puzzling me is why this only affected Windows 7 users (when they went through the NLB), and Windows Server 2012 didn't.  It seemed that Windows 7 machines were constantly being sent to WFE1, and Windows Server 2012 machine was being sent to WFE2.  Surely that defeats the point of load balancing?

SharePoint 2010 Management Shell and Windows Management Framework 3.0

I have four Windows Server 2008 R2 machines which are used for SharePoint 2010.  However, I remotely connect to these machines from my Windows Server 2012 box.  Windows Server 2012 has a pretty nifty Server Manager which allows management of remote servers, but in order to manage Windows Server 2008 machines, it needs Windows Management Framework (WMF) 3.0 installed on the 2008 machines.

I've installed that, and can manage the servers remotely - works brilliantly.  However, opening the SharePoint 2010 Management Shell (PowerShell) now produces the old favourite error message:

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered

I've found (from this post on TechNet) that WMF 3.0 seems to be a bit incompatible with SharePoint 2010. A blog post - Henrik's blog: SharePoint 2010 - Windows update powershell error - recommended uninstalling WMF 3.0 to resolve this.  But I found that adding a '-v 2' parameter to the shortcut for SP2010 Management Shell seems to work quite well so far:

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe -v 2 -NoExit  " & ' C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 ' "

There are some reports that this doesn't completely fix the incompatibility, but I've not encountered any other problems yet.

How to search a list using a Content Editor web part

Had a challenge for a little while - a large list, over 4000 items, that need to be searchable.  Our staff don't want to understand how to use columns to filter, and they like text boxes that they can type in to.

Only found out today that you can search a list using a query string, a la:

http://sharepoint/Lists/Applications/AllItems.aspx?FilterName=Title&FilterMultiValue=*adobe*

This will bring back all items in this list that has a title containing the word "adobe".  Changing FilterName to the name of the column you wish to search will enable you to search other columns as well.

So, with a bit of a kickstart from here - SharePoint List Search in Moss 2007 - I adapted and came up with this code, which you can easily shove into a Content Editor web part at the top of your list page (AllItems.aspx, in this case).

<script type="text/javascript">

function RedirectUrl() {

var cs = document.getElementById("searchText").value;

var url = '';

url = "FilterName=Title&FilterMultiValue=*" + cs + "*";

window.location.href = "AllItems.aspx?" + url;

};

</script>

<div style="border-top: #cccccc 1px solid; border-right: #cccccc 1px solid; background: #efefef; border-bottom: #cccccc 1px solid; padding-bottom: 5px; padding-top: 5px; padding-left: 5px; margin: 10px auto 0pt; border-left: #cccccc 1px solid; display: block; padding-right: 5px; width: 60%">

<h3 style="text-align: center">

Type in this box to filter the list below:

<input class="search" id="searchText" type="text" style="padding-bottom: 10px; padding-top: 10px; padding-left: 10px; padding-right: 10px"/>

<input id="btnSearch" onclick="return RedirectUrl();" type="button" value="Search"/>

</h3>

</div>

If you would like more information on throwing things around in a query string to filter or sort a list, have a look at this lovely blog post: Search, Filter or Sort Lists from a Query String.

Exporting all custom solutions from a SharePoint 2010 farm

Not many updates to the blog lately, apologies for that.  I'm working on moving our current SharePoint 2010 environment to a new server farm, hosted by a new company who insist that we have to rebuild everything from the ground up.

I've been using AutoSPInstaller to automate a lot of the process of building a new farm, but one thing I couldn't find much instruction on is those custom solutions and features we're using.  I didn't want to source every single solution again - some were developed by me, so they're easy to find, but there are others which aren't so easy to find (3rd party contractor developments).

Finally found a solution, from Using PowerShell to export all solutions from your SharePoint 2010 farm and other fun:

(Get-SPFarm).Solutions | ForEach-Object{$var = (Get-Location).Path + "\" + $_.Name; $_.SolutionFile.SaveAs($var)}

So simple, and works exactly as you'd expect.  Now I can pick from all of my solutions which ones I still actually need.