Tuesday, August 25, 2009

Feature.xml and ItemEventReceiver.xml for Event Handler in WSS

If you are going to work with Microsoft Windows SharePoint Services event handler like Item Adding, Item Added and etc, create the following files to implelment it as a feature. Refer the below file contents.

Feature.xml




ItemEventReceiver.xml

Visual Studio.NET Debugging Tips and Tricks

Tip: Use the BreakPoints Window: If you know the name of the class and method you want to break on, you can choose New from the Breakpoints window and type it directly into the Function area of the window. Developers can spend 15 minutes wandering through their projects opening files just so they can position the cursor over a line of code and hit the F9 key to set a breakpoint. If you know the name of the class and method, doing it this way will find it and set the breakpoint. In addition, you can click it in the Breakpoints list of the window and go to the location automatically.

You can also set a breakpoint by just entering the method name, if it is unique in your application. And, if it isn't you will actually get a list of ALL the locations where the method can be found, which is extremely useful for setting multiple breakpoints on a commonly used function throughout your project. It also displays for overloaded methods in the same class.

Tip: Use Hit Counts: In the Breakpoints window, when you right-click and choose Properties and then click the Hit Counts button, you can modify a breakpoint with four possible combinations of choices. Experiment with this to see how useful it can be. What makes this especially useful is that when you have stopped in the Debugger, it tells you how many times your breakpoint has executed. You can also create conditional expressions that will trigger the debugger only if your expression evaluates to true or has changed since the last time it was evaluated.

Tip: Use Assertion Debugging: The idea behind asserts is very simple: When you are writing code, you understand that some condition is always expected to be true. If that condition is ever not true, then there is a bug. Asserts can be written so that if this condition is ever not true, the debugger will be launched at that exact point in your code:

System.Diagnostics.Debug.Assert (myValue >=0)

The nice thing about Assert windows is that they not only give you the opportunity to break or not, they also show you the stack trace at that point. A very powerful, yet highly under-utilized feature.

The file "http://servername/sites/Testing/test123/test.docx" is checked out or locked for editing by SHAREPOINT\system

Whenever you are trying to update the properies of an Item in ItemAdded Event of a Document Library. Need to use base.DisableEventFiring/base.EnableEventFiring before and after an item added. Refer the below sample source code for your further use,

Code Snippet:

public override void ItemAdded(SPItemEventProperties properties)
{
base.ItemAdded(properties);
try
{
base.DisableEventFiring();
SPListItem oItem = properites.ListItem;
oItem["ItemName"] = "Testing";
oItem.SystemUpdate(false);
}
catch(Exception err)
{
Console.Write(err.Message);
}
finally
{
base.EnableEventFiring();
}
}