I'm using Ninject in a SharePoint feature. I've got it working via an HttpModule.

I need to tell Ninject whether I want to use my real or "fake" implementations.

I'm thinking about using a web.config appSetting value to drive that decision. My thinking is that the modification I manually make to my dev SP instance's web.config won't make it into source control or the deployed package.

I understand that manual web.config changes are a no-no in SP. Is this a valid exception?

Where do you put values that you want to exist only in your development environment?


SharePoint offers developers with many options for storing custom configurations settings outside of the application itself. This may vary from Web.config to Property Bags to Lists. I would personally recommend to use Property Bags (Perhaps Web application/Farm level) to store configurations.

Here are some sample on how to use them: http://www.fivenumber.com/understanding-sharepoint-property-bag-settings/

Read more about it: http://msdn.microsoft.com/en-us/library/ee855123(v=office.12).aspx

  • I second the property bag implementation, because it's where sharepoint's own patterns and practices group puts depenedency injection data for it's custom dependency injection framework. May 25 '12 at 14:19
  • 2
    The reason why we are a bit hesitant to go with the web.config approach is two-fold: Manipulating web.config programmatically is often troublesome using SPWebConfigModification, as I’m sure several folks from community can attest from their previous engagements with similar issues ;-). Secondly, using either the ages-old “copyappbincontent”-approach and/or the *.config-injection are not really something that would work for every scenario, or even properly at times. May 25 '12 at 14:37
  • I like the property bag approach. It's very simple, and it can very easily be set using a simple Powershell script (ok for dev)
    – Steve B
    May 25 '12 at 15:18

Lance, I think web.config is the right approach to adding a value that is unique to an environment. We do exactly that in our environment and our deploy process handles the web.config files as well. You could also create a supplemental web.config file. You could also modify them programatically.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.