I looked into this late last year and discovered that there is actually a bug which was not going to be fixed (SP2010). I've written about all the experiences I had with SPWebConfigModification here<http://spmatt.wordpress.com/2012/10/10/jumping-the-hurdles-of-using-spwebconfigmodification-to-update-the-web-config/>
I had a look in SP2013 to see if the issue had been fixed and while it had, it wasn't ideal either because on pre-existing nodes that you modified instead of reverting that change it removed the whole node! My workarounds for SP2010 are documented at the link above. My workaround for SP2013 was to remove all customisations at the beginning of feature activated and apply the new customisations - remove all customisations at the beginning of feature deactivating and reapply the original configuration values. Overall the experience in both versions of SP was hacky at best, but it still beats making manual changes imo. <http://spmatt.wordpress.com/2012/10/10/jumping-the-hurdles-of-using-spwebconfigmodification-to-update-the-web-config/> On Mon, Apr 8, 2013 at 9:25 AM, Web Admin <[email protected]>wrote: > You're very welcome. > > In the case of manual changes for our FBA solution I added the required > config modifications to the build doc. > > > On 8 April 2013 11:05, Mike Hansford <[email protected]> wrote: > >> Hi Paul**** >> >> ** ** >> >> The solution is re-usable and can feasibly be re-deployed across site >> collections / web applications. **** >> >> ** ** >> >> Your suggestion of scoping it to the web application makes a lot of sense >> as the web.config only needs to be modified once per activation. **** >> >> ** ** >> >> The big problem with making manual changes to web.config is that the list >> of these changes is separate from the deployment of the solution. It would >> be easy to deploy it to another location (web app, site collection) and >> forget to make the web.config changes. It will be necessary to build in a >> process whereby you look up a documentation store before activating any >> solution (probably a good idea anyway). As we move from dev to test and >> prod we’d need to make the changes separately on each activation and deal >> with the extra work and potential for errors. **** >> >> ** ** >> >> Thanks for your input. You’ve certainly got me thinking about how I scope >> my solutions.**** >> >> >> Regards**** >> >> Mike**** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *Web Admin >> *Sent:* Friday, 5 April 2013 2:39 PM >> *To:* ozMOSS >> *Subject:* Re: options for modifying web.config for a solution**** >> >> ** ** >> >> Hi Mike,**** >> >> ** ** >> >> How often or likely is it that you'd activate the feature on a site in >> another web app?**** >> >> ** ** >> >> If it was me, I'd be doing it at the web app level and keep a handy copy >> of the required changes for any future apps.**** >> >> ** ** >> >> I've done this both manually (painful but less error prone) and using >> SPWebConfigModification (problematic) on an app-scoped feature.**** >> >> ** ** >> >> Regards,**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> On 5 April 2013 10:17, Mike Hansford <[email protected]> wrote:**** >> >> I have a solution that needs modifications to web.config to work >> (Enterprise Library Logging Application Block and a WCF Client >> configuration). The solution is scoped to a site collection.**** >> >> **** >> >> I have found two possible methods for doing this with feature >> installation / activation – creating a supplemental web.config or using >> SPWebConfigModification in a feature receiver.**** >> >> **** >> >> Of these options, the supplemental web.config will be added to all web >> applications, not just the one/s that the feature is installed / activated >> on. Using SPWebConfigModification has led to being able to add entries but >> not remove them (discussed on SharePoint Overflow - >> http://sharepoint.stackexchange.com/questions/60468/web-config-entries-not-being-removed-during-feature-deactivation). >> **** >> >> **** >> >> So far, I’m left with either of these options as is, or making manual >> modifications each time I deploy the feature to a sith collection within a >> new web application (not desirable).**** >> >> **** >> >> So, what techniques are people using to modify web.config, what problems >> have occurred for them and how are they being fixed?**** >> >> * ***** >> >> Cheers**** >> >> Mike**** >> >> >> _______________________________________________ >> ozmoss mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss**** >> >> ** ** >> >> _______________________________________________ >> ozmoss mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss >> >> > > _______________________________________________ > ozmoss mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss > >
_______________________________________________ ozmoss mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
