I’ve been using a feature of ASP.NET called Output Cache. It allows you to have server-side cache for your ASP.NET webpages. You can define several profiles and cache expiration rules. You can read more about it in a simple and short article at MSDN or in the full documentation also at MSDN.
A feature that I wasn’t able to find was cleaning all the cached data. You can remove cache for a specific page using HttpResponse.RemoveOutputCacheItem(”pagename”) but to remove all pages (which can have several cached versions each) you have to use some kind of workaround. You can use a Cache dependency relying in a item stored in HttpContext.Cache items collection, but for my particular scenario it wasn’t the right solution. Why?
If you have several front-end servers serving your website, you have independent cache systems, so when forcing a cache cleaning, you will force it only for the front-end serving your request. To solve this issue I’ve created a cache system relying on a file dependency. This way, when I change that file, all the front-end servers will clean their cache. I’ve included a CacheManager class that has the usual Add method, that automatically add the file dependency to cached data ( usually using Response.Cache.Add) and not only output cache.
Download source code and have fun exploring it.
If you are an ASP.NET developer you must be familiar with web.config. Something that maybe you haven’t tried yet is to create custom configuration sections to store you application specific settings. Bellow you can see a web.config file that uses a custom configuration section. In the configuration/configSections element you must define which class is responsible for handling your configuration section. Then you can add your custom settings to the file as shown bellow.

The usage of your settings is shown bellow. The configuration section handler class is used in order to access the configuration properties.

I’ve shown you the usage of a class called SiteSettings, but how does it’s definition look? It is a class that inherits the ConfigurationSection class. The configuration section properties are defined by adding public properties that correspond to Configuration Elements. While adding these properties you can define the name of the XML node that you will use in the web.config file and either if the property is required or not. In the example bellow you can see the Singleton design pattern in order do avoid creating several instances of the class and loading the section from the configuration file each time I access the values.

In this example, we only have one configuration property. It is defined in the class bellow. It corresponds to a contact information. Each property of this class correspond to an XML attribute, and by using annotations you can define the name of the XML attribute, it’s default value, if it is required and even add validators such as regular expression validators. You can use several variable types such as strings, integers and event enumerables.

By using custom configuration settings this way instead of accessing ConfigurationManager.AppSettings as a dictionary of string values you get intellisense while using configuration settings, and best of all, automatic validation of the types, constraints and structure of the settings (checked when the settings are accessed for the first time).
The full demo project is available for download. I hope it gets useful to you.
Today I was testing a website using a HTML W3C validation tool (XHTML 1.0 Transitional) and I found a problem in my links. Some URLs had the & symbol, since they linked to dynamic webpages which need parameters. The trivial solution is to replace the “&” occurrences on all links by the equivalent “&” expression. But while changing some dynamically generated URLs I found out an interesting fact about ASP.NET controls vs HTML controls that I was not aware of.
In the example bellow you can see 2 pairs of Links and Images. The first set are ASP.NET controls, the second one are HTML controls (markup) with runat attribute set to server in order to allow their manipulation by ASP.NET code.

When you look at the source code in the client side bellow you can spot a slight difference that can make your HTML validation fail. href and src attributes that originally contained the “&” and which are the result of ASP.NET controls rendering have “&” instead, but the HTML controls still have the invalid &-based URL’s.

Since I had both type of elements mixed in the website, and I was threating them in the same way I was getting different behaviors. Now I know why…
You can find several ways of putting some sample text in a HTML input text which fades away when you click it. Some of them use a few lines of javascript, others take advantage of Javascript frameworks, and there are even ways to achieve it using just CSS (but it doesn’t work in IE anyway). But I haven’t found any guidance on doing it to password inputs. So I did it my way.
The problem
The image bellow shows the desired behavior. When you open the webpage you can see an input with a grayed out message on it, telling the user that it is a password field. When you click the input, you can type your password (without being displayed on the page). If you click outside the input, and it is empty, the “Password” message appears again.

The solution I present is based in Javascript, and you can achieve it without using any server-side technology. But since I had to do this using ASP.NET, I’ll show you an example using this technology.
ASP.NET markup
First of all let’s take a look at the markup. I’ve create 2 textboxes, one using the Password text mode, where you can type text without displaying it on the browser, and another one which is a simple textbox with our “Password” message. I’ve grayed out this message and left the input as readonly, since we don’t need its value.

Disclaimer
As you may know I am a fan of C#, and I don’t like VB.NET that much… But since while writing this demo I accidentally created an VB.NET project, instead of creating another one I took advantage of the opportunity to test my VB.NET skills.
Now I love C# even more…
Javascript Injection
Now lets the the Javascript part of the solution. I use ASP.NET to inject the Javascript into the page in the server-side. I use the Attributes property of the textboxes to set styles and client-site event handlers. In order to hide the real password input when the page is rendered, I set the style attribute of the input element with the value “display:none”. When the fake password input gets focus, the browser hides it, shows the real password input and changes the focus to it. The user doesn’t even notice the input switch, at least if you make sure that the two inputs have the same style. When the password input loses focus (onblur event), if it is empty, the fake input is shown again .

About ClientID
If you are not that familiar with ASP.NET, or at least with client-side scripting used with ASP.NET, you may be wondering that is ClientID. Well, in this example it has the server-side name of the textbox, but when you use User Controls or Master Pages, not always the server-side name of a control is the same that the name/id in the client-side. So the ClientID property gives you the name/id that will be valid while trying to access the control on the client.
What if there is no Javascript support…
Ok, it works fine. And it is pretty clean. But what if by some reason the Javascript is disabled in the client browser? Well… The user won’t have access to the real password input, and will get stuck with the fake input which has the “Password” text and is read only. Even if he could write on it, in the server side the password wasn’t expected from that input anyway. So we need a solution that works even when Javascript is disabled. The user will not have the fancy sample text inside the input, but he will be able to type and send the password to the server. How?
First of all the default visibility status of the inputs will have to change. When the page is rendered the real password input must be visible and the fake one invisible. This way if Javascript is disabled, the user will get a standard password input. After the page is loaded, if Javascript is enabled, we switch the inputs. This switch occurs before the user sees the page, so the final result is the same (while using a Javascript-enabled browser).

The code that the “…” hides is the code of the first VB.NET block.
RegisterStartupScript
This is the method used in order to register script that is supposed to be used in the client side. Page.ClientScript has other nice methods, that allow your to attach onSubmit client-side event handlers and do other client-side Javascript related tasks. Two nice links about RegisterStartupScript are this an this.
You can download the complete source-code of this post.
Today I had to generate files in ASP.NET for download which was supposed to open a save file dialog in the web brower. The file name was based on a title field extracted from a database. The title had spaces which I allowed to be used in the file name (I replaced accents and other invalid characters). In the source code bellow you can see a simple illustrative example.

Perhaps you have noticed that I am generating a plain text file, but I am not using the “text/plain” mime type. When you use “text/plain” the browser automatically knows which application to use for opening the file. If you use “application/octet-stream” instead, the browser uses the file extension in order to find out which is the operating system default program for that file extension. But when you have spaces in you file name as in the example above, you get different behaviours from different browsers.
In Internet Explorer 7, the spaces are replaced by underscores, the the browser recognizes the file extension “.txt”.

If you download the same generated file using Firefox, it cuts the file name ending at the first space. This way the browser considers that your file name is “Just” which has no extension. As a consequence Firefox doesn’t know which application to suggest you for opening the file.

I haven’t tried other browsers, but I took a safe approach. In the server side, while defining the file name I replace the spaces by underscores, this way the download has a consistent behavior in both browsers.