Often I find developers writing custom batch scripts, stsadm commands to deploy their customizations ( Site definitions, field types, event receivers, workflow, and features) to MOSS staging/production farms. This is considered a very bad practice due to the following reasons (but not limited to):
1) A farm disaster happened but luckily you had your scripted backup of your farm. But when you restore, web parts are throwing errors
2) Unable to isolate the WebPart errors as the WebParts were manually installed
3) What about WebPart dependencies? Forgot to restore them!
4) Ok I got the WebPart somehow working (VS debugging etc) but wait where are the images?
5) What about the killer Web.config changes in new farm? Did you back that up too?
6) Now that you fixed the WebPart and customizations somehow, how will you deploy this fix to each server in the farm - manually? What if there are 16 servers in the farm?
Bottomline, always wrap up your customization as a solution package (WSP) prior to deploying to MOSS farm. Even your custom Cascading Style Sheet (CSS) files, .aspx pages, and master pages will need to be deployed via WSP if they are to be used farm-wide. As a general rule, if the item in question will affect the entire farm it will likely need to be deployed via WSP.
Thursday, August 13, 2009
Best practices steps to create a WebPart
When writing your own custom web part, always remember to execute the following steps:
1. Wrap the web part as a *.dll to be deployed to the web application BIN directory to ensure that code access security can be applied.
2 .Create a *.webpart XML file that will specify the above *.dll, namespace, and class for the Web Part and defines properties for it.
3. Create a Feature.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection.
4. Create an Elements.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection.
5. Write a safe control entry for the web application's web.config file that grants permission for your Web Part to run.
6. Set Code access security policies that define what the Web Part will be allowed to do
Once you finish coding your webpart, create a deployment package (*.WSP) before installing/deploying to your farm
1. Wrap the web part as a *.dll to be deployed to the web application BIN directory to ensure that code access security can be applied.
2 .Create a *.webpart XML file that will specify the above *.dll, namespace, and class for the Web Part and defines properties for it.
3. Create a Feature.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection.
4. Create an Elements.xml file that is one of two files used to copy the .webpart XML file to the Web Part gallery of the site collection.
5. Write a safe control entry for the web application's web.config file that grants permission for your Web Part to run.
6. Set Code access security policies that define what the Web Part will be allowed to do
Once you finish coding your webpart, create a deployment package (*.WSP) before installing/deploying to your farm
Subscribe to:
Posts (Atom)
