1.
Every customization must be Feature based
solution.
Doesn't matter if it’s a Webpart/Event
Handler/InfoPath/Content Types or file system change. You can group the
features together as solutions. Solution should have event handlers for
"Feature activating" and "Feature Deactivated" events
wherever applicable. Place the appropriate code in respective blocks. It’s a
best practice to have un-installation module in place.
2.
Be Descriptive:
Ensure that all the
features has a appropriate name, description, updated version number,
optionally icons.
3.
Follow the Four part naming or
at-least Three part naming
In Name Spaces, Solution names, and in the Target
location of the solutions. Don’t just place them inside features folder,
But create a four/three part naming folder for each feature and place the
supported files inside.
for
e.g., rather "statusreport", It would be more meaningful, if it is:
Company.Sales.StatusReport.WebPart, Isn't it? This will avoid conflicts and
provides better manageability.
4.
Follow coding standards.
Each and every Solution must
be thoroughly evaluated line-by-line and
tested in DEV, TEST and then moved to PROD environments. We will do the code
review before moving to DEV even. Follow the coding standards(even in variable
naming! Preferably PascalCase/camelCase)
5.
Avoid de-bugging solution in PROD
environment.
You can write your code in such a way, Errors are getting logged
in to the Event Log / Custom Log file. Fix them in DEV at least. So that it
would be easier for de-bugging.
6.
We must not deploy debug mode assemblies
In PROD - Remove all your Break-Points, and debug codes before packing for
PROD. Make sure your code and packages are compiled in release mode.
7.
Avoid any manual changes.
All changes
must be automated. Even a web.config changes should be scripted. Adding Configurable
Properties to a SharePoint Web Part’s Tool Pane is preferable.
8.
Pay more attention to the Documentation
Pretend like you are giving instructions to the Person who doesn’t know
anything about the particular solution.
we
need guides which should contain
- Solution
abstract, flow, name and version number.
- Activities,
configurations, packages, etc. that should be installed or performed
before/after the package installation.
- Deployment
steps: Detailed steps to deploy or retract the package.
- Unit Test: How
to validate that the package is deployed successfully.
- provide the
exact steps.
9.
Never deploy SharePoint DLLs
Along
with your WSP!!! – what’s the consequences – You will damage SharePoint.
How? Your different versions DLL’s from Development box will cause
In-compatible operations with PROD SharePoint environment.
10.
Never Modify SharePoint’s files in File system.
If you must modify have a backup and make the change as solution. E.g.
Changing the Core.CSS file for branding.. If you Change the file, It may be
overwritten when applying service pack. Never Modify SharePoint Databases!
11.
Use WSP Builder Project Template
Use
Visual Studio 2008 – No Manual DDF files generation! Use Relative Links
Whenever Possible.
12.
Maintain versions
Along with change
history in solutions. The assembly version number should be as the
solution version number and should be incremented (format V#.#.#). So
that we can do upgrade solution, which is faster than going through the
complete cycle, it does only upgrade existing features.
Like SVN, CVS, TFS and keep all the related artifacts there.
14. Double check your Object disposals.
use http://code.msdn.microsoft.com/SPDisposeCheck
15. Don't hard code the parameters
In the code, But make them configurable properties.
16. Handle the exceptions properly.
Use Try{} Catch{} Finally{} Blocks.
17. Use SPQuery instead of SPList.items when retrieving from Large lists/libraries.
18.
Last but not least: Provide excessive comments,
Summary in code wherever applicable
E.g. Use summary on functions like
this:
/// <summary>
/// Function's Summary
/// </summary>
/// <param Name="param1">
/// Why we need param1?
/// </param>
/// <returns>
/// What we get from the function
///</returns>
/// <summary>
/// Function's Summary
/// </summary>
/// <param Name="param1">
/// Why we need param1?
/// </param>
/// <returns>
/// What we get from the function
///</returns>
Event
Receivers
Event handling gives developer the ability to catch
certain user actions in code and react programmatically.
Ex 1: It will not allow any user to delete
any item in that list and user will get
error message.
Ex 2: where
the requirements are to store a bunch of files in a document library,
and then sync "published"
files to another document library.
Ex
3: Event receiver to
prevent files other than PDF from being uploaded to a
document library. So when user tries to
upload a file other than PDF they'll
get an Error message in the window
saying "You are allowed to upload only
PDF files".
The event receiver is attached to all document libraries
of the site where the feature is activated.If you want to attach the Event
Receiver to one single list you have to code this with a custom Feature Event
Receiver.
Various
Events in Event Receivers in Various Levels
The feature has the ability to add custom event handlers to sites,
lists, items and content types in your portal. Portal solution needs to be
dynamic, expect change and work seamlessly with the other systems in your
environment.
Event Types
Here is a list of events that you can hook into:
·
Microsoft.SharePoint.SPWebEventReceiver :
"Site Level"
Occurs after a site collection has been deleted.
|
|
Occurs when a site collection is being deleted.
|
|
Asynchronous Afterevent that occurs after
an existing Web site is completely deleted.
|
|
Synchronous before event that occurs
before an existing Web site is completely deleted.
|
Asynchronous after event that occurs after
an existing Web site has been moved.
|
|
Synchronous before event that occurs
before an existing Web site has been renamed or moved to a different parent
object.
|
·
Microsoft.SharePoint.SPListEventReceiver :
"List Level"
Occurs after a field link is added.
|
|
Occurs when a field link is being added to a
content type.
|
|
Occurs after a field has been removed from the
list.
|
|
Occurs when a field is in the process of being
removed from the list.
|
|
Occurs after a field link has been updated
|
|
Occurs when a field link is being updated
|
·
Microsoft.SharePoint.SPItemEventReceiver :
"List Item Level"
Asynchronous After event that occurs after
a new item has been added to its containing object.
|
|
Synchronous before event that occurs when
a new item is added to its containing object.
|
|
Asynchronous after event that occurs after
a user adds an attachment to an item.
|
Synchronous before event that occurs when
a user adds an attachment to an item.
|
|
Asynchronous after event that occurs when
after a user removes an attachment from an item.
|
|
Synchronous before event that occurs when
a user removes an attachment from an item.
|
|
Asynchronous after event that occurs after
an item is checked in.
|
|
Asynchronous after event that occurs after
an item is checked out.
|
|
Synchronous before event that occurs as a
file is being checked in.
|
|
Synchronous before event that occurs after
an item is checked out.
|
|
Asynchronous after event that occurs after
an existing item is completely deleted.
|
|
Synchronous before event that occurs before
an existing item is completely deleted.
|
|
Occurs after a file is moved.
|
|
Occurs when a file is being moved.
|
|
Synchronous before event that occurs when
an item is being unchecked out.
|
|
Synchronous before event that occurs when
an item is being unchecked out.
|
|
Asynchronous after event that occurs after
an existing item is changed, for example, when the user changes data in one
or more fields.
|
|
Synchronous before event that occurs when
an existing item is changed, for example, when the user changes data in one
or more fields.
|
1. Security:
The assembly you deploy to the Global Assembly
Cache(GAC) is running with full trust. Watch out for the following:
·
Denial of
Service attack:
If a user uploads 10000 items to a list, what is
the effect it will have to
the systems your assembly uses.
·
SQL
Injection attack:
If a user attempts to insert SQL statements into
a column of a list that your
assembly uses to update a database, what
mechanisms are you using to
make sure the input is valid.
·
Cross Site
scripting attack:
What is the effect of adding script to a column
that your assembly uses to
update another area in SharePoint?
2. Performance:
Watch out for the following:
· Load: What burden are you placing on your web front end servers to run the
assembly each time an event occurs? Use performance counters to determine this.
· Long Running Operations: Consider creating a custom SharePoint timer job. Kick off/ Schedule
the Timer Job from the event rather than running all the logic inside the
event. This will allow you to use the features of SharePoint to view whether
the Timer Job ran successfully.
· Sync vs Async Events: Synchronous events have to wait until your code completes before
returning the page, whereas Asynchronous events show the page immediately.
3. Error Handling:
When using synchronous events and you decide to
cancel an event, let the user know why the event was cancelled. For example,
update a Task List with a message why it failed.
Log your errors so that you can determine what
issue is occurring when your system is in production environment.
4. Connections:
Cater for external systems being down when you are trying to connect to
them. Don’t let your code / solution go belly up because you cannot connect to
a database.
5. Bulk Operations:
The MSDN documentation mentions that event handlers
will not fire when bulk operation is occurring. For example, when a new list is
created, the FieldAdding event will not fire.
Limitations of Event Handler in
SharePoint
Strangely there is no
“SiteAdding”, “SiteAdded” event. However, if you really need this event you could
create a “feature” to accomplish this. Features in SharePoint have a
“FeatureActivated” event, where you could perform an action on creation of a
site.
Event Receivers vs Workflows - Decide Which One to Use
As
SharePoint Event Receivers & SharePoint workflows has lot of similarities,
Many people stuck on deciding which one to go with: Event Receiver or Workflow?
Main Differences Between SharePoint Event Receivers and SharePoint Workflows are:
1. Event handlers Can't be manually initiated - workflows can be initiated either automatically or manually.
2. Event Handlers can be Synchronous or Asynchronous - Workflows are always async (They executes after the operation)
3. In Event Receivers we can cancel the operation (such as add/update/delete) - But in Workflows its not possible.
4. Event handlers execute from a Particular WFE, So when some thing goes wrong in that WFE, It may end-up. But Workflow Jobs are robust and can resume even after Reboots.
5. Usually Event handlers runs for short period - Workflows can be longer even for years!
6. There is no User Interface/user Interaction in Event Receivers - Workflows can have user interactions such as getting user input in Initiation forms.
Main Differences Between SharePoint Event Receivers and SharePoint Workflows are:
1. Event handlers Can't be manually initiated - workflows can be initiated either automatically or manually.
2. Event Handlers can be Synchronous or Asynchronous - Workflows are always async (They executes after the operation)
3. In Event Receivers we can cancel the operation (such as add/update/delete) - But in Workflows its not possible.
4. Event handlers execute from a Particular WFE, So when some thing goes wrong in that WFE, It may end-up. But Workflow Jobs are robust and can resume even after Reboots.
5. Usually Event handlers runs for short period - Workflows can be longer even for years!
6. There is no User Interface/user Interaction in Event Receivers - Workflows can have user interactions such as getting user input in Initiation forms.
7. As the Name indicates, SharePoint Event receivers
are triggered by events like New Item Adding-Added, Updating-Updated,
Deleting-Deleted, etc. - But Workflows triggered only on
Creation/Change/deletion.
8. Event Receivers are created using Visual studio - Workflows can be via SharePoint user interface, SharePoint Designer, Visio or Visual studio.
9. Workflows leaves "Workflow History" logs which we can refer for debugging - Event handler doesn't do such.
10. Event receivers are better for large volume - Workflows are better for small amount of data.
8. Event Receivers are created using Visual studio - Workflows can be via SharePoint user interface, SharePoint Designer, Visio or Visual studio.
9. Workflows leaves "Workflow History" logs which we can refer for debugging - Event handler doesn't do such.
10. Event receivers are better for large volume - Workflows are better for small amount of data.
==>> KUMAR NUGALAPU
Senior Consultant
No comments:
Post a Comment