In Visual Studio, while you try to build wsp using WSPBuilder, you receive an error message saying:


========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
WSPBuilder
Version: 0.9.8.0830
Created by Carsten Keutmann
GPL License 2007
Building the solution - please wait
Saving the Manifest.xml file
Creating the WSP file
Could not load file or assembly 'CabLib, Version=6.9.26.0, Culture=neutral, PublicKeyToken=85376ef9a48d191a' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Fix:

Problem occurs when you try to use x64 version of WSPBuilder on x86 machine (usually happens on VMs).

This happens because you have a wrong cablib.dll (x64 instead of x86) in wsp builder’s installation directory. Get x86 cablib.dll and copy/paste it in the installation directory of wsp builder (overwrite the old cablib.dll), usually at C:\Program Files\WSPTools\WSPBuilderExtensions.

If you do not have cablib.dll for x86 platform, get appropriate version (x86) of wsp builder and that comes with appropriate (x86) cablib.dll.

Hope this helps–

In this post, I am going to write an event handler that:

1. is triggered when an item is added to a document library (i.e. ItemAdded)
2. sends an email to some email address notifying that an item has been added to the document library
3. is deployed to a List using SharePoint Features

Okey, lets get started. Create a subsite under your site collection. In the subsite create a Document Library named AlertMe.

JumpStart – > JumpStartWeb -> AlertMe

Create the Event Handler:

Go to Visual Studio 2008. Click File -> New -> Project …..and select Class Library:

Give any name to your project e.g. ”EventHandler.SharePoint.SendEmail.Feature”. This will also become the name of your namespace

Add the directives as shown below:

Top four directives will already be there.

1. “Microsoft.SharePoint” is to use sharepoint object model.
2. “System.Reflection” is to get assembly information as we will need that to register the event handler with the document library.
3. “Microsoft.SharePoint.Utilities” is to send email from SharePoint.

Your namespace name is the name you selected for your project. Rename Class1 to “EmailAlertsEventHandler” and make it to inherit from SPItemEventReceiver class. Rename the class in Solution Explorer window as well:

You might have noted that SPItemEventReceiver class name appears in black coloured font, that’s because we are missing a reference to Windows SharePoint Services.

Lets add the reference as shown below:

Right click “References” -> in the Solution Explorer window and click Add Reference.

Select Windows SharePoint Services as shown below:

As soon as you will add this reference, Microsoft.SharePoint will appear under References and SPItemEventReceiver will change its colour to green which means that it is recognized as a class now.

If you want to see what SPItemEventReceiver contains, press Alt+Cntrl+j, Object Browser window will open. Expand Microsoft.SharePoint -> Microsoft.SharePoint -> SPItemEventReceiver. You will see all the methods in this class in the right hand pane. You will also see the ItemAdded method which we are going to use for our event handler.

Alright, lets add a few methods to our class. As you will write “public override” and press space, intellisence will provide for you the list of all methods available in SPItemEventReceiver, as we saw in the Object Browser:

Select ItemAdded from the list and enjoy the intelligence of VS, you will find a few things automatically done for you:

Here is the  code for “EmailAlertsEventHandler.cs”:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint;
using System.Reflection;
using Microsoft.SharePoint.Utilities;

As you can see in the code above, there are only two functions ItemAdded and AddOrRemoveEventHandler. ItemAdded opens the web, gets the name of the item which invokes the event handler and sends an email to the specified address. AddOrRemoveEventHandler adds the event handler to the list or removes it, depending on the bool value “doAdd”.

Create the Feature Receiver:

Now how do we attach this Event Handler with a specific list. For that we said we will use Features, such that when the feature is activated, the event handler is attached to our list, and when the feature is deactivated, the event handler is detached from the list.

So, we have to write some code to capture Activate and Deactivate events of the feature. Right click on your project in the solution explorer -> Add -> Class ………..as shown below:

Select Class, give it a name like EmailAlertsFeatureInstaller:

Add the directives Microsoft.SharePoint, System.Reflection and Microsoft.SharePoint.Utilities on the top as shown below. Inherit the class EmailAlertsFeatureInstaller from SPFeatureReceiver. You can open the Object Browser to see all the methods available in SPFeatureReceiver..

Before I move to add methods to this class, lemme explain what is SPFeatureReceiver doing here. Every feature can have four events i.e Feature Activation, Feature Deactivation, Feature Installation and Feature Uninstallation. Against these four events, SPFeatureReceiver class provides us with four methods respectively i.e. FeatureActivated, FeatureDeactivating, FeatureInstalled and FeatureUninstalling. These methods will be executed as the events take place. So, if we override these methods and put our custom code inside, our custom code will be executed whenever a feature is activated, deactivated, installed or uninstalled.

And thats what we wanted i.e. when a feature is Activated, our event handler gets attached to our AlertMe document library. And when the feature is Deactivated, our event handler is detached from our AlertMe document library.

Here is the full code for EmailAlertsFeatureInstaller.cs:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint;
using System.Reflection;
using Microsoft.SharePoint.Utilities;

As you can see we have overriden only two methods of SPFeatureReceiver class i.e. FeatureActivated and FeatureDeactivating. On FeatureActivated we get to our list AlertMe and call AddOrRemoverEventHandler with a ‘true’ value i.e. attach the event handler. On FeatureDeactivating we iterate through all the lists and call AddOrRemoveEventHandler with a ‘false’ value i.e. detach the event handler.

Also, you can see above in the code that we have added FeatureInstalled and FeatureUninstalling methods though there is no functionality added to them. This is mandatory, if you will not add these methods you will receive an error message because these are abstract members of SPFeatureReceiver class and we must implement them in our class.  

Alright we are ready to build our project. Try building and it should work.

Put your assembly in the GAC:

Now lets put our assembly (dll) in Global Assembly Cache (GAC) so that it is available to SharePoint. For that we have to strongly name our assembly as it will be placed in a shared location (GAC).

To strongly name your assembly, right click on your project in Solution Explorer window and click Properties:

Select Signing at the bottom and fill the check box saying “Sign the assembly”. In “Choose a stong name key file” drop down, select <New…>. In “Key file name” text box, give name of your project (assembly) like “EventHandler.SharePoint.SendEmail.Feature”……..click OK…….as shown below:

You will that a file named “EventHandler.SharePoint.SendEmail.Feature.snk” has been added to our project. If you click the file, you will see something similar:

Now our assembly is ready to go to GAC. Go to your working directory on the file system, move to \bin\Debug folder e.g.

C:\Work\EventHandler.SharePoint.SendEmail.Feature\EventHandler.SharePoint.SendEmail.Feature\
bin\Debug

Here you will find your assembly i.e. EventHandler.SharePoint.SendEmail.Feature.dll

Open GAC i.e. c:\windows\assembly and drag and drop your dll in the GAC as shown below:

Do an IISRESET.

Create the Feature:

Now comes the second part of our project i.e. to create the Feature. Remember, we have created a Feature Receiver until now, Feature itself is still to be created.

All Features in SharePoint lies in 12 hive under Features directory:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES

Browse through a few Feature directories and you will find that all of them have a feature.xml file……and some will also have an elements.xml.

Lets create a Feature of our own. Create a folder under Features directory and name it EventHandler.SharePoint.SendEmail.Feature………..could be any name..

Go inside the folder, right click -> New -> Text Document and rename the text document as feature.xml file. Create another file in the same manner and save it as elements.xml:

Right click feature.xml file and Open With -> Notepad. Paste the following xml in the file and save:


<?xml version="1.0" encoding="utf-8"?>
<Feature  Id="F2F6FE98-7A4C-4db7-B1E3-BC9C6E5CC9D7"
          Title="EventHandler SharePoint SendEmail Feature"
          Description="Email Alerts for AlertMe Library"
          Version="1.0.0.0"
          Hidden="FALSE"
          Scope="Web"
          DefaultResourceFile="core"
          ReceiverAssembly="EventHandler.SharePoint.SendEmail.Feature, Version=1.0.0.0, Culture=neutral, PublicKeyToken=74b4a55dc039bd07"
          ReceiverClass="EventHandler.SharePoint.SendEmail.Feature.EmailAlertsFeatureInstaller"
          xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="elements.xml"/>
  </ElementManifests>
</Feature>


Note that you have to be careful about four items in this xml. Feature Id, ReceiverAssembly, PublicKeyToken and ReceiverClass. They could be different in your case, so use the ones that you have.

For PublikKeyToken, go to GAC, take properties of your assembly and copy/paste into your feature.xml.

Feature Id is just a GUID. Here is how you can get one of your own:

Go to Visual Studio, click Tools ->Create GUID. If Create GUID option is greyed out, click Tools -> External Tools. Make the following settings as shown in the figure below and click OK. This will enable Create GUID option.

“Initial directory” in VS 2008 will be
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\

Click Create GUID and you will receive it as under:

Click copy and paste it into Feature Id in feature.xml as shown above.

Open elements.xml and paste the following xml into it:


<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
</Elements>


Install and Activate the Feature:

Alright, coool, our feature is ready to be installed now.

Open the command prompt and move to the Features directory. Enter the following command:

stsadm -o installfeature -name EventHandler.SharePoint.SendEmail.Feature


After you have received the “Operation completed successfully” message, navigate to your site in SharePoint. In my case the heirarchy was JumpStart -> JumpStartWeb -> AlertMe.

So, I’ll move to JumpStartWeb -> Site Actions -> Site Settings ->  under Site Administration click Site Features. You will see your feature available there as shown below:.

Click Activate button in front of your feature to Activate the feature:

Test your Event Handler:

Go to your document library, in my case it is AlertMe and upload a document:

As soon as you upload the file, you should receive an email to the address specified in your event handler:

Hope this helps–

First, we have to read from “Person or Group” field.
It could be a “Person or Group” field that allows one user to be selected.
It could be a “Person or Group” field that allows multiple users to be selected.
If its a single user, get user, get his email address, send him email.
If there are multiple users, get each of them one by one, get their email addresses, send them emails.

Do not copy/paste the code; and if you do, look for the typos ; should be mostly alright though….
and also be careful coz inverted commas sometimes doesn’t get copied propertly from a web page….

So the quesiton is where can you put this code? Could be an event handler that sends an email to a user when an item is added to a document library. How to do that, look here:

http://rehmangul.wordpress.com/2009/11/17/writing-event-handlers-and-deploying-using-features/

Hope this helps–

I am happy to share the news that Microsoft has announced MVP [Most Valuable Professional] award for me for the third consecutive year….

https://mvp.support.microsoft.com/profile/rehman

It’s been a gratifying experience…..

It is important to understand the differences between MOVING, MIGRATING or UPGRADING a farm:

http://technet.microsoft.com/en-us/library/cc262370.aspx

I’ll slightly touch these at the bottom of this article. Mainly, I am going to discuss approaches how can you MOVE from one farm to another.

MOVING to another farm:

If you are moving from a test farm to a production farm, this  involves MOVING a farm. You must have similar hardware (32-bit or 64-bit which ever) and you must have similar software (version of sharepoint, windows, all software updates) and you must have similar topology (server names, number of servers) on the farm you are MOVING to.

The reason is becasue the configuration database and the Central Admin database contain computer-specific information. For that reason, you can only move to a new farm if you can configure it to be exactly the same as your original farm. Configuration database will not work for a new environment where topology, server roles or software updates are different.

Okey, if you do not have the same hardware, software or topology, then what to do? Then you should move everything in the farm except Configuration and Central Admin databases, and configure the new farm on your own, wihout expecting this to be done by the restore procedure, since we are not restoring configuration database. OR, you should consider MIGRATING or UPGRADING:

http://technet.microsoft.com/en-us/library/cc262370.aspx

So, let talk about MOVING to another farm. Microsoft says this is the way to “Move to another farm”:

http://technet.microsoft.com/en-us/library/cc261918.aspx

This page has a lot of information, hidden and obvious, I wish to consolidate it here:

There are three possible ways through which you can Backup and Restore your farm (note that I said backup/restore, not move):

1. STSADM
2. Central Admin
3. Sql Server (lets ignore DPM and the others for the time being)

But there is only one way to MOVE your farm to another farm and that is:

• Sql Server (tools)

MIGRATING to another farm using STSADM and Central Admin (tools) is regarded as obsolete. That means if you are moving to a new or different farm, you should not use Central Admin or STSADM command. So, moving or migrating whatever you may want to call it (because here it just means moving to a different environment), STSADM and Central Admin approach is obsolete. (I couldn’t find anywhere where Microsoft supports/permits you to MOVE to another/different/new farm using STSADM or Central Admin). 

http://technet.microsoft.com/en-us/library/cc262281.aspx (Migrating through Central Admin (Obsolete))

http://technet.microsoft.com/en-us/library/cc263236.aspx (Migrating through STSADM (Obsolete))

We can restore our farm using STSADM and Central Admin, only on the SAME farm from which the backup was taken i.e. no new farm is involved at all:

http://technet.microsoft.com/en-us/library/cc261704.aspx (Restore using STSADM)

http://technet.microsoft.com/en-us/library/cc262928.aspx (Restore using Central Admin)

If you will use Central Admin, you will select “Same Configuration” option for the “Type of Restore” radio button. And for STSADM, you will use “overwrite” value for “-restoremethod” parameter. Using Central Admin, you can take farm level backup but it will not let you restore Central Admin and Configuration databases saying that “Central Admin and Configuration databases cannot be restored from this user interface”.

 Now the only way left while moving to a new farm is SQL Server (tools):

http://technet.microsoft.com/en-us/library/cc261918.aspx

After we have reached this decision, remember that there could be two possibilites:

1. Your new farm on which you are restoring may have different specs from the farm from which the backup is taken from. Specs means server names, software updates, number of servers.
2. Your new farm may have exactly the same specs as the farm from which the backup is taken from.

If you plan to move Config and Central Admin databases, your new farm MUST have the same specs. If your new farm has different specs, then you should not move Config and Central Admin databases.

“Move to another farm” (http://technet.microsoft.com/en-us/library/cc261918.aspx) provides a step by step procedure to move to a new farm, and it assumes that sharepoint is already installed on the destination farm, which essentially means that Configuration and Central Admin databases are already created. So, if you have the same specs for your new farm, you can go ahead and overwrite Config and Central Admin databases, this will restore the configuration from the backup set.

Now it could be the case that you can live without moving Configuration and Central Admin databases to the new farm i.e. you will configure the new farm by yourself and you dont need to transfer Config and Central Admin databases from your old farm. So, what will you move then:

1. Content Databases
2. SSP Databases
3. Search Databases for SSPs
4. Search Databases

However, above databases can also be restored using Central Admin and STSADM approaches.

Summary: Moving to a new farm involves SQL Server and a farm with similar specs, otherwise do not move Config and Central Admin databases.

If you are looking to Move only the Content Databases, here is the one stop shop:

http://technet.microsoft.com/en-us/library/cc262792.aspx

MIGRATING to another farm:

If you are changing from 32-bit hardware to 64-bit hardware, this will also be a MIGRATION process (i.e. change in hardware specs as mentioned earlier). If you are planning to change your existing SharePoint Server 2007 platform to Windows Server 2008 (platform), you might have to change to 64-bit hardware. And to upgrade Microsoft Office SharePoint Server 2007 to a 64-bit environment, you must migrate existing servers to a new farm. You cannot upgrade Office SharePoint Server 2007 directly from the 32-bit edition of Office SharePoint Server 2007 to the 64-bit edition.

http://technet.microsoft.com/en-us/library/dd622865.aspx

UPGRADING a farm:

 Upgrade is when you are moving to a different version of SharePoint Server e.g. from SharePoint 2003 to SharePoint 2007.

 If you are moving just the database server (all databases including Config and Central Admin) and not the whole farm, look here:

http://technet.microsoft.com/en-us/library/cc512725.aspx#Section1

If you wish to ditch the farm level backup/restore and just move your website (site collection) to the new farm (and save yourself a lot of hassle), have a look here:

http://rehmangul.wordpress.com/2009/04/18/sharepoint-site-backup-and-restore/

After release of SP2 and CU for April, you can safely backup and restore your site collections to a new farm, without worrying about absolute URL issues:

http://blogs.technet.com/stefan_gossner/archive/2009/05/01/red-is-green-up-is-down-and-the-unsupported-suddenly-becomes-supported.aspx

Hope this helps….