Category: ASP.Net Development

Maintaining ViewState consistency in a web farm environment

Originally written on June 2006 

This message is relevant to all of us who build ASP.Net applications that are being deployed into a Web Farm/Garden. A small modification will have to be done in the web.config to avoid view state inconsistencies.

The problem is that the ViewState on ASP.Net pages are encoded based on a Key. By default an application will use the key on the machine.config file, which is auto generated, thus, different in every machine (server). If an application runs in a web farm, then there is a potential of having inconsistencies in the way the ViewState is encoded/decoded.

The solution is to set a the key used for encoding in the web.config… and setting it to a static key. This way all the encoding/decoding of the ViewState will be done with the same Key, and there will be no problems. Plus the Key will have an application scope, instead of a Server scope (which has when uses the machine.config).

The setting in the web.config is something like this (the one below is an example only):

<system.web>
  <machineKey validationKey=”21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4″  decryptionKey=”261F793EB53B761503AC445E0CA28DA44AA9B3CF06263B77″ validation=”SHA1″ />
  <!– OTHER SETTINGS –>
</system.web>

It is recommended to have different key setting for each application. Here are a key generator:

Machine Key Generator

So, basically, if our application is on a web farm, or we think it will be, it is recommended to add a machine key section in our web.config.

ASP.Net 2.0 web application deployment

Originally written on April, 2006 

ASP.Net 2.0 has introduced a few new different concepts in regards of dll generation and deployment.

 In ASP.Net 1.x, all your class files would get compiled into 1 dll and that was it. In the new world there are actually 3 options:

  1.  You release everything including class files and they get compiled on the fly. This means nothing of the web application gets copied to the bin folder.
  2. You release only binaries. Everything, including ASPX pages are pre-compiled (If you open the ASPX file after the compilation you can’t see your client side code). This means everything is in the bin folder, pretty much one precompiled file per file in your application.
  3. A mix of the 2 above (and the most similar to ASP.Net 1.x). Every class gets compiled, but ASPX pages remain normal. Even in this scenario, multiple dlls get generated per project. 

One of the main challenges here is the version management; you can not implicitly assign versions (no AssemblyInfo.cs in web apps), plus there are multiple assemblies generated.

However, there is a command that will merge all your dlls (per application) into one, applying versions, signatures, etc. The utility command is called aspnet_merge.exe. It is important to know what it does, but notice that we won’t have to use it directly as Microsoft has now released it as an Add-On for Visual studio.

The Add-On is really easy to use, and I would recommend we all get familiar with it. You can get it here: http://msdn2.microsoft.com/en-us/asp.net/Aa336619.aspx