Disable Event Firing in SharePoint

A colleague of mine just sent me this code. Disable Event Firing from anywhere in your code.

 
  public class HandleEventFiring : SPItemEventReceiver
  {
     public HandleEventFiring()
     {
     }
     public void CustomDisableEventFiring()
     {
        this.DisableEventFiring();
     }
     public void CustomEnableEventFiring()
     {
        this.EnableEventFiring();
     }
  }

Use like this:

 
  SPWeb web = site.RootWeb;
  SPList list = site.RootWeb.Lists["Testing"];
  SPListItem item = list.GetItemById(2);

  //update item properties
  
  HandleEventFiring eventFiring = new HandleEventFiring();
  eventFiring.CustomDisableEventFiring();
  item.SystemUpdate();
  eventFiring.CustomEnableEventFiring();

Intergen wins Enterprise Content Management category at Partner Awards

A couple of weeks ago Microsoft New Zealand had there annual Partner Awards. I am pleased to announce that we won the Business Productivity Enterprise Content Management Solution of the Year award, based on the work we did building the New Zealand Trade and Enterprise SharePoint website. Microsoft received nearly 100 applications, and there were 17 categories to be won.

The NZTE project was significant in a number of respects. It was one of the country's first truely successful public-facing SharePoint sites, and has received notable commendations and favourable reviews within the industry, and from NZTE itself. NZTE's CEO, Tim Gibson, says: "The new website is fantastic, and is going to be an important part of our delivery as an organisation going forward."

This was a huge effort by all involved an one that I personally take a lot of satifaction from.

Microsoft Office SharePoint Server (MOSS) Content Deployment

Content Deployment is a powerful part of Microsoft Office SharePoint Server (MOSS). It can also be a bit of a challenge in highly customised environments. Recently I had the task of enabling Content Deployment in an Internet-facing situation.

The situation was pretty typical. An Internet-facing site that contains content authored by people on an internal network separated by a firewall. The internal authors need to have the ability to author, edit, and approve content, but also ensure that this environment is shielded from incoming Internet traffic for security purposes.

The brief was to enable content deployment between a site on the client's internal authoring environment and a publicly accessible site in their external DMZ publishing environment. Content deployment needed to run an incremental deployment every hour and a full deployment nightly.

We had some initial problems but managed to overcome these. This is a record of what happened and how we solved these issues.

A little disclaimer: It is very important that any custom developed components are created in-line with SharePoint best practice. Shortcuts in this area will lead to a lot of extra effort further down the track.

Content deployment does not deploy any custom code or file system artifacts. These components have to be present in both the Internet-facing and internal authoring environments for content deployment to succeed. In our situation we had a couple of masterpages, a number of page layouts, and about 20 odd SharePoint custom field controls. Most of the issues we encountered were around the custom field controls.

SharePoint Content Deployment has 3 distinct stages, exporting from the authoring site, transporting to the Internet-facing site, and finally importing at Internet-facing site.

1) The first problem we encountered was that we could export our content successfully from our authoring environment but were unable to import this content into the Internet-facing site.

This was solved by deploying our custom code or file system artifacts to the Shared Services Provider (SSP) on the destination farm.

2) We then had a requirement to add validation to the custom field controls. We followed an article on MSDN (http://msdn.microsoft.com/en-us/library/ms434697.aspx) to implement validation. The first approach in this article suggested that we validate the actual field. This method of validation worked perfectly in the authoring environment. However we encountered problems when we were importing into the destination Internet-facing site.

This was solved by changing our validation strategy to only validate the UI of the control (see second approach in the above article). Theoretically any value could be saved to the field, but if you were using the user interface to save a value (which the content authors were), then only certain correct values could be saved.
What we observed was that by validating the actual field rather than just the UI of the control we were crashing the content deployment process.

3) About this time we were worried about our ability to debug future Content Deployment issues. We investigated ways of using the API to create a Custom Content Deployment application, and can be seen in action in the SPDeploymentWizard codeplex project(http://www.codeplex.com/SPDeploymentWizard).

This was pretty easy to do. We created a console app with some configuration switches to change Import/Export, and logging levels. The major advantage with this is that you can configure the app to have much more verbose logging than is typical with SharePoint OOTB. Basically you can print a line for every object that is being exported and can find the exact object that is causing the deployment to fail.

4) We then created and deployed two new custom field controls, and again the content deployment stopped on the Export.
The controls were created in exactly the same way as the previous controls. If we excluded the controls the content deployment worked fine. The controls were definitely deployed correctly as we could use them within the authoring environment.

To fix this we restarted all the servers. I noticed an error occurring from some code that was no longer present within our solution. I could only infer that SharePoint Content Deployment was caching a temporary version of the DLL somewhere. The restart flushed this cache, and content deployment started immediately.

This didn't take too long to write down but took a while to work out at the time. Hopefully this is useful for someone when they are in the process of enabling content deployment in the future.

New Zealand Trade and Enterpise SharePoint WCM site is now live

We have been hard at work on the new New Zealand Trade and Enterprise website (www.nzte.govt.nz). This has been my first publicly accessible SharePoint WCM website, after working on a couple of WCM extranets.
This was a huge challenge leading a big development team with a short timeframe and a lot of functionality to pack in.

Check it out and let me know what you think.

We learnt a lot on this project so I'll try and get a few posts up over the next month.