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
