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):
<machineKey validationKey=”21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4″ decryptionKey=”261F793EB53B761503AC445E0CA28DA44AA9B3CF06263B77″ validation=”SHA1″ />
<!– OTHER SETTINGS –>
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.
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:
- 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.
- 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.
- 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
In this post I will discuss how I implemented the Profile Management for Network Trotters .
Profile Management Generals
As an application developer, you get the opportunity to place some information in the user profile page. Specifically you can set a Profile Action (link below the Profile Pic) and a Profile Box.
In your application you basically tell the Facebook platform where it should get the FBML/HTML that defines both the Profile Action and Profile Box. It is important to notice, that Facebook will Cache this FBML/HTML, until you specifically tell them to refresh it.
So in summary, you set the user Profile from your application, but you have to build a mechanism to refresh the users profile periodically.
I am using the Facebook Development Toolkit as the Facebook Platform API wrapper; and the profiles are set by using Urls.
.Net Implementation (one of many)
In my implementation, the profile management contains 3 main components:
- Profile Content Page
- Setting a user profile
- Refresh the profile
Continue reading “Facebook Profile Management”
After much procrastinating, I have finally decided to start my blog to talk about my experiences, both professional and personal.
The main subject will be software development in Microsoft’s Technologies; the intent is to share my experiences so I can collaborate to the community of .Net developers out there.
I run my own Software Development company (Web Nodes), so I encounter many different challenges daily; most likely other developers are running into the same kind of issues… For a while now I have been only consumer of information: it is time to start giving back 🙂
Feel free to suggest any topic, I’ll do my best to provide you with insights or samples if possible.