Brian Mains Blog : Frameworks

Encrypting or Decrypting the Configuration File

bmains — Wed, 04 Feb 2009 14:08:00 GMT

Since .NET 2.0 and Visual Studio 2005, the ability to encrypt the config file has been possible. This functionality is built-in to the aspnet_regiis.exe utility. This executable uses flags to designate a few items:

-pe for encrypting web projects registered with IIS
-pd for decrypting web projects registered with IIS
-pef for encrypting web projects using the Cassini (local) web server
-pdf for decrypting web projects using the Cassini (local) web server
-app for specifying the IIS registered virtual

To encrypt the connection strings settings, use the following approach:

aspnet_regiis -pe "connectionStrings" -app "/Virtual"
aspnet_regiis -pef "connectionStrings" "c:\websites\virtual"

To decrypt, use the following:

aspnet_regiis -pd "connectionStrings" -app "/Virtual"
aspnet_regiis -pdf "connectionStrings" "c:\websites\virtual"

This can be run even when Visual Studio is open; you'll be prompted that the file changed and do you want to reload it.

The difficult aspect to this is that the account that encrypts the password has to decrypt it, or you will get the "unable to descrypt connection strings error." Obviously, this is impractical. The way to get get around this is to add the account that will run the ASP.NET application (for IIS 5.1 on XP, this is the ASPNET account, but in Windows Server 2003 and IIS 6, it's the NETWORKSERVICE account). To grant permissions for these accounts to decrypt the connection string in the application, use:

aspnet_regiis -pa "NetFrameworkConfigurationKey" "NT AUTHORITY\NETWORK SERVICE"

See more about this at: http://msdn.microsoft.com/en-us/library/yxw286t2.aspx. This grants the account permissions, and the automatic decryption can works successfully.

You do not need to write any code to decrypt the values; these values are automatically decrypted, with no apparent performance issues.

Deploying Changes to an ASP.NET Site

bmains — Sat, 07 Oct 2006 04:31:00 GMT

I deployed changes to a site, and it turns out I had an error in the configuration file. I made a change, deployed the new file, and still had an error. I tried to figure out what it was; the error messaged showed the new configuration file, but still had the same previous error. In deploying all my ASP.NET pages, it reloaded the compiled files for the pages, and used the new configuration, correcting the problem. I had remembered some about this from reading Dino Esposito's book; because the site wasn't recompiled, it was still using my previous configuration file. Still seems strange though.

Encrypting the Connection String

bmains — Sat, 07 Oct 2006 04:26:00 GMT

If you need to encrypt or decrypt the connection string, I found a great resource that you can access. It is available on: http://aspnet.4guysfromrolla.com/articles/021506-1.aspx. It shows you how to do it programmatically, and through the aspnet_regiis utility.

One point to note; I used the RSA provider, and I got an error when deploying to a remote host. I don't know if the encryption needs to be established on the remote server, or if it was that the provider was not installed on the host machine. I can't think it would be the latter, so ensure that it works before you deploy.

UrlMappings Element

bmains — Tue, 05 Sep 2006 16:04:00 GMT

I was excited to see the <urlMappings> element. When enabled, you can specify url's that when entered into the browser will redirect to another page. For example, take the following section:

While not the best examples, they illustrate the point. When you go to link.aspx, newlink.aspx will display; however, link.aspx will show in the browser. You can also use this to hide querystring values, so that when you go to weather.aspx page, the right querystring value is provided.

More information is available at: http://msdn2.microsoft.com/en-us/library/ms228302.aspx

.NET Framework Recognizing Changes

bmains — Tue, 29 Aug 2006 23:56:00 GMT

I was working with my application the other day, and upon saving a page, without closing the browser, I realized that the framework detected the change immediately and automatically. I was astonished at how that worked; I could tell it was working because you could see it was taking a lot longer to process the page, like it usually does when you first load the application.

I saw about this reading Dino Esposito's Programming Microsoft ASP.NET 2.0 Advanced Applications. Upon compilation on the first page load, the page is compiled, which it notes the file dependencies. Upon updating the page assembly, it is renamed with a ".delete" extension, which is OK to do and won't cause an error. This occurs every time that the page assembly is updated, up to a maximum number of times (set in the web.config file), and then the application is restarted.