Tuesday, March 20, 2007

From time to time I need to find out if the code that is currently executing runs in a Hosted Environment (like ASP.NET application) or not (like Windows Forms application). Mostly those kind of knowledge might be needed in reusable assemblies which deal with file access. For ASP.NET application you almost always need to call Server.MapPath method (or one of the equivalents). For Windows Forms Application you either do nothing or call something like Application.StartupPath.

There are many ways to tell if code is hosted or not. Usually I see code similar to the following:

if (HttpContext.Current == null)

This code however requires a reference to a System.Web.dll which may not be something you take lightly :-). So I thought: lets see how They do it - that is how Microsoft does it.

It appears that they use a System.Web.Hosting.HostingEnvironment.IsHosted property to make this check inside System.Web.dll. Still this is a System.Web.dll that you have to reference to make the check. I have been unable to find any alternative that does not require this reference, but hey! I'm a web developer mainly and I have nothing against referencing System.Web.dll :-)

Tuesday, March 20, 2007 11:11:26 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Monday, March 19, 2007

I have always believed that each collection is by definition IEnumerable. That belief held true until today...

First let me define my loose definition of what a collection is. A collection is a set of objects. In .NET Framework I have noticed a special pattern for naming collection classes - they usually end with a Collection word. Examples include dozens of collection classes in System.CodeDom namespace, AttributeCollection or even ControlCollection. I'm so used to this kind of naming convention that when I see it I automatically know that I can do a foreach loop over it.

There is however at least one exception from this rule and that is a System.Web.UI.CssStyleCollection class. It is a class that derives directly from System.Object and it does not implement any interface which means no IEnumerable!!! When I looked at the public properties, they suggest that it should really be a collection. It has an indexer, it has a collection of keys and values. It even has a Count property not to mention all the usual methods for manipulating collection-like objects.

Strange, but true :-)

 

Monday, March 19, 2007 4:56:11 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  | 
 Tuesday, March 13, 2007

Every once in a while while working with ASP.NET there comes a time when you need to have a DropDownList with a fixed set of items. Or maybe the items are retrieved from the database, but still every instance of the control will have exactly the same items. How to do it efficiently?

Lets look at the simple example of a DropDownList with country names - the one you see on many pages. Wouldn't it be nice to have a reusable control for this?

The simplest way to create a Self Populating DropDownList is to inherit from the standard one, set the DataSource somewhere and call DataBind(). That is the tricky part.

If you have been working with ASP.NET for a while you are probably aware of the ViewState thingy. As good as it is, it can often make your page too large. This is specially true for DataBound controls. A simple Counties DropDownList would make your ViewState huge! So what can be done about it? Just disabling ViewState won't help because usually disabling it breaks some of the other parts of control's functionality.

Dealing with ViewState is simple once you get to know one very important thing. Only changes made after the Init phase of the Life Cycle are persisted to the ViewState! Or more precisely, changes only changes made after the control has started tracking ViewState (TrackViewState method has been called). It means that everything you put to the ViewState before that, will not be persisted. By default controls will have their TrackViewState method called right after the Init phase.

We can use this knowledge to our advantage. If we populate our DropDownList before or during the Init phase we will not affect ViewState. Doing so however has one drawback: we have to perform this operation on each request and not only when IsPostBack is false. This is not an issue if we use some kind of cache and we populate a lots of controls with the same data.

kick it on DotNetKicks.com

Tuesday, March 13, 2007 9:35:32 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

There are a lot of articles on how you can debug you JavaScript code using Visual Studio 2005. There are basically two cases:

  1. Debugging ASP.NET pages inside the Visual Studio's solution.
  2. Debugging other pages - not included in the solution.

In the second case, all you have to do is attach to a process of a running Internet Explorer using Debug->Attach to Process... menu option, in the first case, all you need is to run the solution in debug mode.

The rest of the scenario is the same for both cases. Visual Studio allows you to open any script document currently loaded into the Internet Explorer process you are currently attached to. This is done via the Script Explorer window which you can turn on using Debug->Windows->Script Explorer menu option or by using the Ctrl + Alt + N keyboard shortcut. The window should look more or less like this:

The problem is that more often than not, debugging JavaScript in Visual Studio simply does not work! I have spent countless hours trying to find the solution or even the cause of this problem, but without success. There are many "solutions" on out there but none of them really solves the problem. Most of them simply don't work! Probably Microsoft fails to acknowledge this as a problem since it has been around for few years now - judging by the news group posts dates.

Tuesday, March 13, 2007 9:32:03 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  | 
 Friday, March 09, 2007

There is a bug in Visual Studio 2005 (but I think I have also seen it in Visual Studio 2003) that causes multiple break points to be set in case you have few files with the same name opened using Script Explorer window. (if you are fortunate enough to have it working).

Steps to reproduce the problem are simple. Just ran a simple page with a Textbox and a Button control and some kind of Validation control. This will ensure that the presence of two "WebResource.axd" JavaScript includes: one for with Validation code and the other one - the standard ASP.NET one. Try to set a breakpoint in the first line of any of the script files included. Use Script Explorer window to get the files. Notice that the breakpoint appears in both files. Also sometimes the focus is moved to one of the other files. Imagine having a couple of scripts included in such a way and all those unneeded breakpoints!

As mentioned above, I have noticed this behavior also in Visual Studio 2003, but I have not tracked it down. I'm almost sure however that there was also the same type of problem also with normal files included in the solution. (yet again, I can't remember for sure).

Fortunately removing breakpoints works correctly so you can remove unnecessary breakpoints once they are created.

As a side note. While writing this article my Script Explorer windows stopped working and this also means that script debugging inside Visual Studio also does not currently work, so I'm unable to provide any more details. I hope though that Microsoft will correct this problem sometime in the future.

Friday, March 09, 2007 5:45:48 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, March 07, 2007

Every ASP.NET developer knows (or at least should know) about the Life Cycle. Page has it's Life Cycle, controls have theirs Life Cycle (more or less the same as the one of the Page). There is a good article on MSDN regarding the Page Life Cycle. From it, you will learn that at any given moment, the Page and all controls are in the same "phase" of the Life Cycle, be it Init, Load, PreRender or Unload.

The interesting part about the Life Cycle is when it comes to dynamically added controls. The controls you add in code using Controls.Add call. Since controls also have the Init, Load and PreRender and Unload phases, what happens when we add a new control during a PreRender phase? As stated above, Page and all controls are always in the same phase. So what happens?

The same article explains this phenomenon and calls it "Catch-up". What it basically means is that at the time of adding a control to a Controls collection, the new control "walks" through all it's phases until it "catches-up" with the current phase of it's parent control (i.e. Page).

In order to better understand this, you can use the following example. On your page override an OnPreRender method and add a following code:

protected override void OnPreRender(EventArgs e)
{
    base.OnPreRender(e);
    Button b = new Button();
    b.Load += new EventHandler(b_Load);
    b.Init += new EventHandler(b_Init);
    b.PreRender += new EventHandler(b_PreRender);
    b.Unload += new EventHandler(b_Unload);
    Controls.Add(b);
}

You will also need to create the event handler methods. As the next step, put a break point on each of those handler methods and run the debugger to see what happens. You will notice that when control is added to a collection of Controls, it's events are fired immediately to catch up with the phase of its parent.

kick it on DotNetKicks.com

Wednesday, March 07, 2007 4:19:03 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  |