We have a SharePoint farm with multiple WFEs. A new application requires us to write some custom code to the web.config during deployment. What is the best way modify the the web.config file during deployment, ensuring that each WFE in the farm get updated?
I'm assuming you'll be deploying your code via a WSP; if not, using a tool like WSPBuilder is a great starting place that allows you to get rolling without forcing you to learn all of the intricate details of solution package construction.
You should leverage the SPWebConfigModification type from within a custom SPFeatureReceiver. Normally, the FeatureActivated method of the SPFeatureReceiver would be coded to write the changes out to the web.config files impacted by your activation. Those same changes would then be retracted in the FeatureDeactivating method.
The nice thing about the SPWebConfigModification type is that SharePoint takes care of determining which web.config files should be modified -- across servers and across extended web apps.
I hope this helps!
As part of your deployment, use the SPWebConfigModification class to add/remove entries from web.config. SharePoint will manage updating the WFEs for you if you use this.
A blog post entitled, Modify the web.config file in SharePoint using SPWebConfigModification, is a great summation of the gotchas involved and contains links to other helpful resources.
Related
I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
I've a farm scoped feature which has an event handler. The feature is activated by default on installation. After I installed the feature I found that the FeatureActivated event has been raised mutiple times (I've three web apps in total excluding central admin and it is called three times).
Because of this the feature deployment is extremely slow (as I'm doing some webconfig modifications for each web application).
Any ideas?
I have had a similar problem in the past. I created a static flag in the FeatureReceiver that indicates if it has triggered before.
Dirty, but effective.
If you make it a farm scoped feature, then the first install we be easier, sure, but then in 6 months when you create another web application, the settings wont be applied automatically and likely forgotten.
If though, you make it a web application scoped feature with the property ActivateOnDefault="TRUE" in your feature definition, then the feature will be activated in all new web applications when they are created.
http://msdn.microsoft.com/en-us/library/ms436075.aspx
And i hope you are using SPWebConfigModification to make the web.config changes, otherwise if you add new servers to the farm, then the web.config mods wont be applied either.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx
Do you need these web.config changes for all the web apps ? Including central admin ?
The first change I would do is to make it a Web Application scoped feature and selectively activate on required web application.
Also, do not make it Activate by default on installation. If you are deploying through script, have a separate command for activation. That way, you can easily debug if the bottleneck is in deployment or activation.
I want to change the trust level of a Sharepoint Web Application without having to change the web.config manually (i.e. WSS_Minimum, WSS_Custom, etc). Making manual changes to the web.config tag is highly undesirable in anything other than a one-server farm. Is there any way via stsadm or Central Admin to change this?
Third party tools or a Powershell script would be acceptable in that they would make clear that there's no native way to accomplish this.
Thanks in advance
See my answer here. There's an object model call to propagate web config modifications to every server in a farm as well as a freely available Central Admin plugin that wraps the OM in an easier to use interface.
There is a class designed for this called SPWebConfigModification that will propagate your changes to all member servers of the farm.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx
-Oisin
SPWebConfigModifications are a pain.. but this stsadm extension will make it a lot easier.
Create a CAS policy?
I am developing publishing site and it will have complex tree structure.
Is there any way to deploy site structure (multiple sub sites - SPWeb) using SharePoint solution?
I know I can create site tree programmatically.
I have been on a project with the same needs, but we didn't find the answer with the OOTB functionality of the feature framework. We also had to go through the object model and do the creation programmatically.
But instead of hard-coding the site structure, we took a different approach. Our solution was to implement a generic SiteCreation feature that takes an xml file as input. The xml defines the site structure and is read by the feature receiver which parses it and creates the specified sites.
I know that there is some coding involved in this solution, but I think the extra work is well spent, since the site structure will likely change numerous times before it reaches production.
The default publishing portal (and collaboration portal) site definitions use a portal provisioning class to build the site structure based on an xml file (this is all out of the box for a MOSS installation).
You can see how the provisioning class is referenced in the webtemp file for the portal site definitions (12\TEMPLATE\1033\XML\webtempsps.xml). An example of the actual xml documents that are used can be found in 12\TEMPLATES\SiteTemplates\WebManifest - it's a fairly straight forward schema.
If you are creating a custom site definition based on publishing portal then you can re-use the provisioning class and provide your own xml document to build your custom site structure.
Using the SharePoint API, how can I modify an extended webapp web.config file?
I have to do some changes in this file to specify the connection string, membershipprovider, etc... for using Forms Authentication.
Currently, I can change the "master" webapplication web.config file, but not the extended one.
Edited
I'm using Sp 2007. I'm already using SPWebConfigModification class to modify the parent webapp. Thoses modifications are propagated to the extended webapp. I have to change ONLY the extended one. But I don't find the way to do it.
What I'm trying to achieve, is to program a little wizard that:
Shows a WebApp list so the user can select one
Extend that selected webapp to a different zone
Configure that extended zone to use Forms Authentication
Thanks
I got an answer form a blog.
In your case , you need to write a Web Application scoped feature which after you provision your site using your C# app, it is deployed to the newly-provisioned site and in the receiver of the feature you inject the required web.config settings because in that context configuration API is obtainable , but again bear the following in mind:
If you don’t use SPWebConfigModification class and either use ASP.NET 2.0 configuration API or your own mechanism , propagating changes across the farm is YOUR RESPONSIBILITY. If this happens on an standalone installation then you don;t need to be worried about this.
So it cannot be done externally. We have to do a feature in order to acheve this.
Thanks
Quick answer: look into the SPWebConfigModification class. I am assuming you're using SharePoint 2007. The best way to learn about this is to dig into open source projects:
Google code search: http://www.google.com/codesearch?q=spwebconfigmodification&hl=en&btnG=Search+Code
This project on CodePlex looks like it's one big SPWebConfigModification: http://www.codeplex.com/ajaxifymoss/Release/ProjectReleases.aspx?ReleaseId=13360