The dotNET blog

I've been working from projects to projects for the last 2 years with a few breaks, so I didn't had time to keep posting fresh posts about the .NET world.  I will try, in 2010, to share with you guys all the things I've learned (and there's a LOT!).

But for now, I'm taking a few moments to ask for your help.  As all of you may know, Haiti was hit by a major earthquake on January 12 2010.  Those people really need our help.  One of my good friend is from Haiti.  He lives in Montreal right now, but his family is still living there.

After the earhtquake, we tried to get in touch with the family as soon as we learned the news.  They finally contact us this morning with fresh news.  Thankfully, just a few scratches.  But the house is GONE.

I'm not the Red-Cross or the Salvation Army.  But I want to help.  I've told my friend that I would do everything in my power to raise some money to help the family rebuild their lifes. This is where you guys can help.  Please consider to make a little donation using the link below.  If one of my articles was useful to you in any way, please take the time to donate to help those people in needs.

You can donate any amount you want.  I will personnaly send all the money raised to the family directly thru my friend.

I hope that this message will find his way.

Thank you for your help.

A great idea from Peter Bromberg, original article can be found here

---

If you are like me, you are always looking for ways to make your programming life easier - reusable class libraries and controls being a prime target of this effort. One of the things that annoys me about ASP.NET 2.0 is that it offers an ASP.NET menu control, but I just can't bring myself to like it. Sure, it's highly configurable, works with SiteMap xml data, and so on. But, regardless of the amount of tinkering I"ve done, there always seems to be some little annoyance about it's behavior that "gets my goat".

For the kind of development I do, I rarely need one of those fancy-schmancy multilevel javascript callback xpealidocious bodacious scriptabobulous menu thingies. All I need is what I like to call a "MenuStrip". Its a control that lays out items that link to to where you want to go, and it fits with the CSS and design of your page. I don't need dropdowns because if you click an item, you go to that page where I would have another one of these with page-specific items on it, including a "HOME" item that can take you back to the home page (or to where you came from). You can drag the control into a ContentPlaceholder on your page, set an XML source file for the menu items, and you are done.

What I"ve done here, since I couldn't find one already done - that I liked, is to create such an animal, with these features:

1) The CSS to match my page layout is inline in the ASCX page portion of the control. It's not a lot of CSS, so I'd rather have it "keep it's own". If I ever need to change it for another site, that's easy to do.

2) The control loads the XML to display its contents into a DataSet, and caches it for speed. It also sports a file-based CacheDependency so that if I want to change the items on a particular menu, all I need to do is edit the small Xml File that specifies them. When the file is changed, the Cache Item gets invalidated and the control automatically reloads the modified file, updating my changes instantly.

3) You can specify the name of the Xml file to use as a property of the control - so each MenuStrip on each page knows exactly which Xml file to use for the items it is supposed to display.

Here's an example of what one looks like, minus the page, and I also have a separate page where you can look at images of two different versions:

Here's a link to the bigger pictures.

When you download this solution, I'm going to include a MasterPage and two Default pages with two different versions of the control on them, so everything will integrate nicely in a nice site layout. The original CSS Layout came from a free template for SNews, a PHP CMS application; I've converted it to a nice MasterPage.

Now let's look at the code for the ASCX codebehind:

You see that the Menustrip control has a public MenuFile property which allows us to specify the Xml File in the declarative markup for the control, like so:

<uc1:ucMenu ID="UcMenu1" runat="server" MenuFile="Menu.Xml" />

Then, I have the control load the required file into a DataSet, Cache it and set a file-based CacheDependency, and it proceeds to "fill in" the NavigateUrl and Text Properties of a bunch of blank Hyperlink Controls that I have in the HTML Markup portion of the ASCX "Page". The rest is done via CSS. You can have as many "blank" Hyperlink controls in the HTML markup of the ASCX as you think you may have menu-items, controls that aren't populated by the code simply don't show up.

This may be a little different approach than other "menu" thingies that you have seen, I hope you like it. The solution you can download below has two fully working versions of the control, and the items point to actual pages on eggheadcafe.com (we'd like you to stick around while you are experimenting with it).

One last item - this is a WAP (Web Application Project) NOT a "WebSite" project. If you haven't installed the WAP add-in, you will find that the solution does not load. You can find out more about WAP along with a link to the download at ScottGu's Blog here.

Download the Visual Studio 2005 Web Application Project Solution that acompanies this article

ASP.NET 2.0 offers you several ways to set a dependency between a cached item and a file(s), another cached item(s) or SQL Server database table. No doubt they satisfy most of the real world needs. However, at times the features offered by these dependencies are not sufficient. In such cases you can create your own dependency and use it instead of inbuilt ones. In this article you learn how this can be accomplished.
Read more...

Do you have an ASP.NET application ready and now you want to translate it into different languages, or are you developing a new application for which you want to support localization? If yes, ASP.NET 2.0 makes it easier than ever before to do so.

More details here

The concept of Caching was introduced in ASP.NET 1.X and has been improved significantly in ASP.NET 2.0. Caching allows you to store commonly used items in the memory and thus not create them from scratch when they are requested. There are different types of Caching available in the .NET framework. In this article the author will introduce us to Caching dependencies.

In some ways, view state is the greatest thing since sliced bread. After all, it’s view state that allows pages and controls to persist state across postbacks. That’s why you don’t have to write code to keep the text in a TextBox from disappearing when a button is clicked as you did in classic ASP, or requery a database and rebind a DataGrid following a postback.

But view state has a dark side, too: when it grows too large, it’s a silent performance killer. Some controls, such as TextBoxes, are judicious with view state. Others, notably DataGrids and GridViews, emit view state in proportion to the amount of information displayed. I cringe when I see a GridView displaying 200 or 300 rows of data. Even though ASP.NET 2.0 view state is roughly half the size of ASP.NET 1.x view state, one lousy GridView can easily cut the effective bandwidth of a connection between a browser and a Web server by 50 percent or more.

You can turn off view state for individual controls by setting EnableViewState to false, but some controls, particularly DataGrids, lose some of their functionality when denied the freedom to use view state. A much better solution to taming view state is keeping it on the server. In ASP.NET 1.x, you can override a page’s LoadPageStateFromPersistenceMedium and SavePageStateToPersistenceMedium methods and handle view state however you like. The overrides shown in the code below prevent view state from being persisted in a hidden field and persist it in session state instead.

protected override object LoadPageStateFromPersistenceMedium ()
{
    string key = Request.RawUrl + "_VIEWSTATE";
    object state = Session[key];               
    return (state == null) ?
        base.LoadPageStateFromPersistenceMedium () : state;
}

protected override void
    SavePageStateToPersistenceMedium (object viewState)
{
    string key = Request.RawUrl + "_VIEWSTATE";
    Session[key] = viewState;
} 

Storing view state in session state is particularly effective when paired with the default session state process model—that is, when session state is stored in memory in the ASP.NET worker process. If session state is stored in a database instead, then only testing will show whether keeping view state in session state improves or degrades performance.

The same technique works in ASP.NET 2.0, but ASP.NET 2.0 offers a simpler means for persisting view state in session state. You begin by defining a custom page adapter whose GetStatePersister method returns an instance of the .NET Framework SessionPageStatePersister class:

public class SessionPageStateAdapter :
    System.Web.UI.Adapters.PageAdapter
{
    public override PageStatePersister GetStatePersister ()
    {
        return new SessionPageStatePersister(this.Page);
    }
}

Then you register the custom page adapter as the default page adapter by dropping an App.browsers file like the following into the application’s App_Browsers folder:

<browsers>
  <browser refID="Default">
    <controlAdapters>
      <adapter controlType="System.Web.UI.Page"
        adapterType="SessionPageStateAdapter" />
    </controlAdapters>
  </browser>
</browsers>

(You can name the file anything you like as long as it has a .browsers extension.) Thereafter, ASP.NET will load the page adapter and use the returned SessionPageStatePersister to persist all page state, including view state.

One downside to using a custom page adapter is that it acts globally for every page in the application. If you’d prefer to persist view state in session state for some pages but not for others, use the technique shown in the first snippet of this article. Additionally, you can run into issues with this technique if a user creates multiple browser windows within the same session.

Microsoft has developed its own approach to AJAX development called Atlas, which promises browser ubiquity as well as tight, albeit optional, ASP.NET integration. In this column, we survey the Atlas architecture to get a better understanding of how you may use it in your development work.