Background
We recently had some questions come up on what are the best practices for pushing out custom configurations into SharePoint, especially across the farm. Many of the custom SharePoint solutions you write will need to push out a custom configuration to a web.config (database connection string) or even have to push out custom configuration file (like a log4net.config).
After some discuss here are some approaches with some considerations for each.
Use a Feature
Whatever you do we recommend using a Feature to do the deployment. Going through an alternate method or even manual can introduce errors. SharePoint Features are meant to provide a way to deploy files and solutions across your entire SharePoint farm.
Provision to 12 Hive
Scenario – How do you deploy a custom configuration file?
Approach - One solution is to provision a file to the 12 hive of SharePoint. In the manifest.xml of the WSP solution package use the <RootFiles> element to push the file to a specific location. For instance <RootFile Location="CONFIG\MyCustomConfig\Foo.xml" />. This will create a folder call MyCustomConfig under CONFIG in the 12 hive and place a custom config file there. You can use this approach to push the file anywhere inside of the 12 hive.
Considerations:
- This file will be accessible to all web applications. This actually will be a good approach for many solutions.
- Your calling solutions within SharePoint (let's say a web part) will have to be able to access these deployed files. You will need to have proper Code Access Security FileIOPermissions to access the files. We recommend keeping your security level a minimum and adding a CodeAccessSecurity tag to you manifest.xml of the web part only. For more information on how to deploy Code Access Security with web parts, please read this - http://www.k2distillery.com/2009/06/deploy-web-part-as-feature-with-cas.html.
- If you like this approach but you need to deploy out custom configurations per web application you can do the following. Create a separate Feature for each web application and set the Feature scope=WebApplication. Then deploy and activate the Feature to the appropriate web application. However calling applications (web part for example) will have to know which directory to go to within the CONFIG directory.
Feature Activation
Scenario 1 – How do you deploy a custom configuration value (like a database connection string)?
Approach – A well accepted approach is to use SPFeatureReceiver in a Feature to push out the changes. One approach would be to use the SPWebConfigModification object to push on the changes on activation (FeatureActivating) and remove the changes on deactivation (FeatureDeactivating). For more information on SPWebConfigModification please read this detailed blog on the topic http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32. As well read this http://weblogs.asp.net/wesleybakker/archive/2009/01/21/web.config-modifications-with-a-sharepoint-feature.aspx
Scenario 2 – How do you deploy a custom configuration file?
Approach – Again use SPFeatureReceiver however you will have to write some different code that will push the file to the location of your choice. Here is an example to get started from http://geekswithblogs.net/bjackett/archive/2009/12/01/deploy-files-to-sharepoint-web-application-virtual-directories-at-feature-again.aspx
Considerations
- Requires custom code.
- Small note - if new web servers are added, the configuration values will not be pushed to the new web servers unless the Feature is deactivated and then activated again.
Deploy to 12 Hive Bin
Scenario – How do you deploy a custom configuration file?
Approach - We found a trick described in this blog that will push a file into the bin of the web application - http://oricode.wordpress.com/2008/02/27/deploy-a-xml-file-in-your-sharepoint-solution-to-the-web-application-folder/
Considerations
- This directory is really meant for binaries. We do not consider this a good approach.
Final Thoughts
All of the solutions listed here we believe to be valid solutions however you need to use the right one based on the scenario you need to support.
No comments:
Post a Comment