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]<mailto:[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]<mailto:[email protected]>
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

_______________________________________________
ozmoss mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

Reply via email to