Jaap Vossers' SharePoint Blog

Just another WordPress.com site

Archive for the ‘Development’ Category

SharePoint Asynchronous Event Receivers and the powershell.exe process

with 5 comments

We recently had a very strange problem with one of our custom Event Receivers in our production SharePoint environment. The Event Receiver implemented the Asynchronous ItemUpdated event. It was used to generate and set a value on one of our fields on the document being updated. The code in the Event Receiver appeared to work most of the times, but would fail at seemingly random occasions and would leave the updated document without the generated field set.

We were struggling to isolate the combination of factors that made it fail. The weirdest thing was that there were no errors to be found in the ULS logs or the Event Log. We added lots of logging and try/catch blocks, but for some reason when the Event Receiver failed it would never enter the catch block, so there was no exception to log.

One key point that helped us with the troubleshooting was that we had noticed that the Event Receiver ALWAYS worked when the document was being updated through the SharePoint web UI. We also had a PowerShell script which was used for bulk updating of documents. This script was scheduled to run at regular intervals using Windows Task Scheduler. It appeared that the issue only occurred when the Updated event was triggered via this scheduled PowerShell script, but even then it still seemed intermittent as it would often work just fine.

We were unable to reproduce the issue at all when calling the ps1 file directly from the PowerShell console. So what was different when the script was run from the Task Scheduler vs directly from the PowerShell console? Well, the Task Scheduler actually calls a BATCH script which in turn invokes the PowerShell script which fires up a new PowerShell process. This process dies when it finishes execution of the ps1 file!

Remember, our Event Receiver is an Asynchronous one, so it would not block the execution of the PowerShell script. The Event Receiver is actually executed on a thread inside the PowerShell process since the ps1 script triggered the Updated event. So, when the PowerShell.exe process dies, it does not seem to wait for any background threads to complete, which in our case causes our Event Receiver to suffer from a sudden death. I was a bit surprised to see this to be honest!

Anyway, I guess one of the reasons why in our case the problem seemed to be appearing randomly is that only the last document in a batch would be affected, which sometimes meant 1 in a couple thousand documents. Only recently users had started feeding the script with “batches” consisting of just one document, which is what highlighted the problem to us and lead to this investigation. We were wondering what had changed recently (we had not touched this part of the code for a while!), since it was all working fine before (we thought), but in reality the bug had always been there but it had never occurred to us!

So everyone please beware when invoking PowerShell scripts from BATCH scripts when you have Asynchronous Event Receivers in your SharePoint environment!

What did we do to work around our problem? We just put a little Sleep at the end of our PowerShell script‚Ķ ūüôā

Written by jvossers

February 3, 2014 at 10:10 pm

SharePoint InlineSiteSettings 2010 – improved productivity for Administrators and Developers

leave a comment »

After having released¬†SharePoint InlineSiteSettings for SharePoint 2007 a while ago, and having used a little desktop application called Launchy which is used to start desktop applications using just a few keystrokes, I decided to build an enhanced version of InlineSiteSettings, built for SharePoint 2010 with features similar to Launchy’s.

The end result is SharePoint InlineSiteSettings 2010, which can be downloaded from CodePlex at http://sitesettings2010.codeplex.com/

inlinesitesettings2010

The purpose of the solution is to improve productivity for SharePoint 2010 users who regularly access the Site Settings page, i.e. SharePoint Administrators and SharePoint Developers. It allows them to access the Site Settings in a dialog by pressing Ctrl+s, so no need to move your mouse to Site Actions, click it, click Site Settings, and wait for the full page to load.

As we all know, once the Site Settings page has been loaded, it can actually take a few seconds to spot the link you are looking for (as the links are not listed in alphabetical order), so what’s new in this version of SharePoint InlineSiteSettings is that users can start typing the title of the link they whish to navigate to, and with real-time filtering functionality, all links that do not match your filter will disappear from view. In addition to that, as soon as exactly one link is left that matches your filter, it will automatically redirect you to that page, as can be seen in the demo screencast below. As a result, navigating between administrative pages in SharePoint 2010 will be less painful.

SharePoint InlineSiteSettings 2010 is packaged as a Sandbox Solution, and does not depend on any server side code. The good thing about this is that it works on SharePoint Online (Office365).

Download SharePoint InlineSiteSettings 2010 from CodePlex

Written by jvossers

May 8, 2011 at 9:59 pm

Bypass caching with jQuery AJAX GET requests

with one comment

As I seem to use this trick quite often and I keep forgetting the exact details on how to implement it, I thought it would be good to document this.

Using jQuery, I often make ansynchronous GET requests to¬†a custom¬†ASHX handler in SharePoint’s _layouts folder which returns some data that I want to display. This data is always dynamic, but sometimes the browser tries to cache the results from the previous request, so you might not get the response you expected.

To avoid this, simply make the url for eacht request unique by adding a timestamp to it in javascript.

var url = '/_layouts/MyProject/MyHandler.ashx?unique=' + new Date().getTime();

Written by jvossers

January 11, 2011 at 10:41 am

Minimal implementation of a custom templated ASP.NET control using the ITemplate interface

with one comment

Below you will find a code snippet to demonstrate a minimal implementation of a custom ASP.NET control that allows page designers to specify a template which will be used by the control to render itself, using the ITemplate interface.

Markup:

   1:  <my:MyTemplateBasedControl runat="server" id="myTemplateBasedControl1">
   2:      <MyHeaderTemplate>
   3:          <div>
   4:              Some text <asp:Button runat="server" Text="And a button..." />
   5:          </div>
   6:      </MyHeaderTemplate>
   7:  </my:MyTemplateBasedControl>

Control code:

   1:  public class MyTemplateBasedControl : CompositeControl
   2:  {
   3:      public ITemplate MyHeaderTemplate { get; set; }
   4:   
   5:      public MyTemplateBasedControl()
   6:      {
   7:   
   8:      }
   9:   
  10:      protected override void CreateChildControls()
  11:      {
  12:          base.CreateChildControls();
  13:   
  14:          // If <MyHeaderTemplate></MyHeaderTemplate> was supplied
  15:          // in the page that contains this control, then this.HeaderTemplate
  16:          // will automatically be set for you with an object of type
  17:          // System.Web.UI.CompiledTemplateBuilder
  18:          if (this.MyHeaderTemplate != null)
  19:          {
  20:              // let's instantiate multiple instances of our template
  21:              for (int i = 0; i < 10; i++)
  22:              {
  23:                  // This will "convert" the string supplied inside
  24:                  // <MyHeaderTemplate></MyHeaderTemplate> into 0 or more controls.
  25:                  // Each of these controls will be added to this.Controls
  26:                  // since we pass in "this" into the InstantiateIn() method
  27:                  this.MyHeaderTemplate.InstantiateIn(this);
  28:              }
  29:          }
  30:      }
  31:  }

Result:

itemplate_result

Written by jvossers

May 12, 2010 at 3:35 pm

Posted in ASP.NET, Development

Released: SharePoint WebPartSlices

with one comment

I have recently released my sixth CodePlex project (list of all my CodePlex projects), titled SharePoint WebPartSlices.

To all the jQuery fans РSorry, no jQuery this time! SharePoint WebPartSlices is a server-side solution that allows users to transform all Web Parts on a page into IE8 Web Slices simply by adding the webslices=1 querystring parameter to the url of the page containing the web parts to be transformed, basically allowing you to add web parts to your IE8 Favorites Bar.

webpartslices1

Voilà РNo need to navigate to the original page to see the updated Web Part.

webpartslices2

Installation consists of a WSP deployment + Feature activation only.

SharePoint WebPartSlices on CodePlex

Written by jvossers

February 4, 2010 at 12:06 pm

Released: SharePoint 2010 Developer Dashboard Visualizer

with 5 comments

As announced before, I have been working an open source project that visualizes the data in the Developer Dashboard in SharePoint 2010.

The good news is that SharePoint Developer Dashboard Visualizer is now up on CodePlex.

SharePoint 2010 Developer Dashboard Visualizer is a jQuery-based solution that extends the Developer Dashboard by plotting an interactive diagram with data from the Developer Dashboard, giving you an **instant** insight into where the bottlenecks are in your code.

(yes, well spotted…¬†I was stupid enough not to rename my machine before installing SharePoint 2010)

The installer is just a WSP so it’s a quick and easy install!

Finally, a big thank you goes out to Bil Simser for being the first person to post a review for SharePoint Developer Dashboard Visualizer online.

Written by jvossers

December 13, 2009 at 10:12 pm

Context in SharePoint 2010 Business Connectivity Services (or the lack of it)

with 9 comments

The problem I see with Business Connectivity Services is the lack of context available when writing your custom code to retrieve and update data. As a result, custom BCS implementations are not very reusable because the lack of configuration options per External List.

Let’s look at an example.

ACME Ltd, an ISV focusing on selling SharePoint products, wants to develop and sell a BCS solution that allows customers to create External Lists based on data that resides in ANOTHER SharePoint site collection. In a nutshell, the External List will contain a “virtual” list item for each site in the target site collection. Now how does the BCS code know where this target site collection is? You could hardcode the url, or you could store the url in the appSettings in the web.config for your web app. These are both solutions that will give you headaches when you need more than one instance of this External List, each using the same BCS code, but¬†retrieving¬†data from¬†different target site collections.

When I created a new Business Data Connectivity Model in Visual Studio 2010 for the first time and I looked at the code that was initially generated (Entity1Service.cs), I was surprised that there seemed to be no way to derive any of the following in code:

  • SPWeb instance or url of the site that contains the External List we are trying to load data for.
  • Name (or ID) of the External List we are trying to load data for. This, together with an SPWeb, would allow you to read per-list configuration data from SPList.RootFolder.Properties
  • Some string containing configuration data that applies to our BCS Entity to External List association.¬†Something similar¬†exists for EventReceivers and Workflow, so why does it not exist for BCS?

I would be very interested to hear people’s thoughts on this subject.

Written by jvossers

December 13, 2009 at 1:10 pm