Encrypted Config Sections…

One of the limitations of our designers is that it does not support encrypted appSettings entries. After talking to customers, however, we have realized that this it is not a common scenario to encrypt the config sections during design and that it is usually done at deployment time. In fact, an advantage of the new Web Deployment Projects is that it allows you to replace web.config sections with the the encrypted section for the target machine.

What I'm interested in knowing is if you feel that my assertion above is, in fact, incorrect and why. This information will help us reconsider the decision.



Comments (2)

  1. Jeff Parker says:

    I would say your assertions are half correct. Allow me to explain.

    The biggest pain in asp.net development in my opinion is deployment and the web.config. You will as a developer use different settings, in development and production, and test. You will be using a test database, production database, and development database, so it will have a different connection string for each stage as well. You may be using different encryption keys, and IV’s as well (long debate where to store these or where to store the paths to them). You will probably have different urls to web services if you are building those as well. I have even used different smtp servers for mailing.

    Now the web config is a great place to set this stuff up. However when you go into production now you have to change all these then you encrypt them there. So now here in lies the problem and the reason I at least do not even bother encrypting things in the webconfig in development. Because I am going to have go in and completely change everything after I deploy it and probably change them several times. Then you need to make a backup of your changes, and now you can no longer just deploy anymore. Or you have to do a selective file copy. However, if you replace that web config with your dev web config and your production app is hosed. So anyway this leaves me with multiple copies of a web config one for production one for development and one for test environment. So I do not even bother with encryption until deployed to production. Too much of a headache. It would be nice to be able to encrypt things all along the way even for test. I guess my whole point to this is I do not encrypt early on not because the designer doesn’t support it, but because it is not practical.

  2. Ali Pasha says:

    Thanks Jeff,

    I really appreciate your taking the time to elaborate on this. This is really useful for not only triaging the appropriate bugs, but for also taking this scenario into account when doing our planning for the next version of the product.

    I’ve forwarded your insights to the rest of my team.


Skip to main content