In my ealier post, I had mentioned that I was a reluctant blogger, which is still the case. Howerver, it make sense to blog if I am going to save time for someone else.
Modiying the web.config is not something new, there are blogs which covers a similar topic. My intention is to share the complete process and the code that works. As of now, I am only going to provide instructions and the screenshots, but as soon as I find some free time, I will upload the entire project. As the current project is part of the bigger project.
My intention is to automate the defaultProxy settings in the web.config.
Remember SharePoint farm can have many servers. Making a manual entry on each server is not a wise choice. Therefore, deploying via feature will come in handy for today and for future configurations especially for a Disaster recovery scenario. Even when you add a new SharePoint server to the farm, these configurations are automatically applied.
Before changing the Web.config programmatically, the web.config proxy settings will look as shown below
After changing the web.config programmatically
<proxy proxyaddress="http://proxy.godwin.net:8080" bypassonlocal="true" />
<add address="[a-z0-9\.]+\.godwin\.com" />
<add address="sharepoint\.godwin\.net" />
Please note – the above url is just an example.
1) First create a visual studio project – using Empty SharePoint Project template
2) Within the Empty SharePoint Project, add a new Feature with Web Application scope. Obviously name the feature using a friendly and appropriate name.
3) Right click on the newly created Feature node and add an Eventreceiver to the feature
So when the solution is deployed and when this feature is activated, I want the web.config changes to be applied. Suppose if I have to deactivate and retract the solution, then I want the changes to be reverted.
To achieve this, I will have to write the code that makes the web.config changes or additions within FeactureActivated and I should write the code that reverts the web.config changes in the FeatureDeActivating event as shown below.
The entire code that you need to make the proxy change in the web.config is shown below.
I am using SPWebConfigModification class and xpath to safely add and remove modification from the Web Application web.config file. SPWebConfigModification has many benefits over other APIs that will allow you to modify the web.cofig entries.
With SPWPWebConfigModification every change has an owner. In the above code, I have assigned the owner as „SharePoint.ApplyProxyConfiguration, which is the project assembly name. Because every change has an owner, based on the owner value, it is easy to revert the change that is made by a specific assembly or feature. Also the SPWebApplication class has a SPWebConfigModifications collection property that contains all the modifications (SPWebConfigModification objects) made to this web application’s web.config file.
The output of the following Xpath is shown in the second screenshot below
The above Xpath adds the <proxy ........../> line as shown below.
SPWebConfigModification includes the following properties
· Name - Gets or sets the name of the attribute or section node that should be set.
In the above example Proxy is the new node. To add an a new node or to modify an existing node under the path which is the next property, you can simiply write
· Path - Gets or sets the XPath expression that is used to locate the node that is being operated on.
In the above example, the original path in the web.config is
Which is simply written in the XPath as -
· Owner - Gets or sets the owner of the web.config modification. This will have to be the unique name. In the above example, I am using the assembly name. However, you can also consider either Feature name or feature id.
· Sequence - Gets or sets the sequence number of the modification.
· Type - Gets or sets the type of modification that is implied by the class. The following types are supported
EnsureChildNode - Specifies that the web.config modification must ensure the existence of a child node of the node to which the XPath expression points.
EnsureAttribute - Specifies that the web.config modification must ensure that there is a value for a particular attribute.
EnsureSection - Ensures a singleton node. This node is only written once, even if multiple entities register multiple instances of EnsureSection to ensure the existence of a section. Please do use EnsureSection, unless you do not want to remove this section. Nodes created with EnsureSection cannot be removed.
· UpgradePersistedProperties - Gets the collection of field names and values for fields that were deleted or changed.
· Value - Gets or sets the value of the item to set. In the above example it is
Suppose if you are writing the feature to simply change an existing attribute in the web.config. for example, you want to change from <customErrors mode="On" /> to <customErrors mode="Off" />
Then the xPath code should look as shown below
I hope the above explanation helps. Very soon, I will try to include the entire project part of the blog post.