For people starting out with ASP.NET, the appSettings node in the web.config file will be all that is necessary for storing configuration items, but when you start creating your own config section handlers and strongly-typing your configuration items, you may run into a small snag that may cost you 1/2 a day to track down.

Configuration section names (since they are xml) are case sensitive.  Xml is case sensitive.

 

I have a section:

<configSections>

<section name=”SiteMap” type=”WebTestHarness.SiteMapConfig, WebTestHarness” />

</configSections>

but if I call:

ConfigurationSettings.GetConfig(“siteMap”);

I get mysterious errors elsewhere in my code.  My config section didn’t get loaded.  It turns out that the section “siteMap” wasn’t found.  “SiteMap” is the correct name.   Of course, I expected the .GetConfig() method to throw an exception if the section wasn’t found, but it doesn’t.  It just returns nothing and lets my code keep going.

 

Now, armed with this knowledge, I will just check the return value of the method to determine if the GetConfig was successful.

If for some reason you need to capture page output either to log it, analyze it or do a global string replace, then you will need to intercept the rendered Html before it makes it to the wire on the way to the client.  Here is a code snippet that will do just that.

The StringBuilder will get the content, and you can do with it what you please.  Then just make sure to call writer.Write( ) to render the final content to the Response stream.

A CheckBoxList can be useful, but have you ever tried to disable a single checkbox in the list?  There are a lot of people who want to do just that.  Here are some ways to do it.

http://www.mredkj.com/vbnet/CheckBoxListItemDisable.html
http://www.codeproject.com/aspnet/disableListItems.asp

There are a few things to keep in mind when you create controls on the fly and add them to your page.  Simply put, you want to add them to the page hierarchy as soon as possible.  Before they are added to the page, they have not initialized themselves.  When a dynamic control is added to another control, the new control plays catch-up to get to the stage that the parent control is in.  For instance, if in your Page_Load, you add a textbox, it will play catch-up and go through its Init and Load phases.  This is important beceause it will start tracking its viewstate.  Values added before it is tracking viewstate won’t make it to viewstate and will be lost on PostBack.  Here is an example that won’t work:

This example shows setting a text property BEFORE this control is added to the page (and before it is tracking viewstate).  Next, we’ll show the right way to do it:

Note here that we add the control to the page BEFORE we set a property.  This enables our dynamic control to participate in viewstate as well as the rest of the page lifecycle.

To clarify, if we add a dynamic control during the Page’s PreRender, when we do the Controls.Add( ) function, the new control will go through Init, Load and PreRender immediately to catch up with its parent (the Page).

There are some basic things in a large web application that change from page to page, and it might benefit you to make that information come from a file or database.  All my base pages implement an interface of mine that contains basic information that my whole site needs.  Standardizing on this interface makes my site more maintainable, and I can implement the properties any way I need to.  Here is my interface:

.Net 2.0 has a PreInit event where the theme and master page can be set.  When you are rolling your own theme or master page in v1.1, you need a time for the end page to set or override the them and master page.  Here is how I created a PreInit event that fires before I wire up the theme and master page:

I shadow the existing events in my base page and then control the raising of those events.  In that way, I can do some work, raise PreInit, do some work, and raise Init.  I chose this method particularly for the ease of migration to v2.0 next year.

Maintaining Scrollback Position Across Postbacks

 

You much check out this post from Scott.  I was just about to the verge of rolling my own scroll-retaining javascript when I read this.  The credit really goes to Steve Stchur and his article on 4Guys.

 

SmartNavigation only works for the most trivial website.  When you do anything custom (anything besides drag-n-drop development), smartnavigation breaks your page, and it won’t even post back.  This scroll problem is an issue for ASP.NET since the postback method is widely used. 

 

I have run across some older user will bad eyesight, and they are at 800×600 resolution, so they do A LOT of scrolling both vertically and horizontally.  Retaining scroll position will mean a better user experience for them.

I was performing some testing, so I commented out a bit of my ASP.NET markup with <!– –> because, after all, I’ve used that for years, right?  Well, it took me just a sec to figure out that the server control was still being executed and that the <!– was just rendered before it on the client.  The important bit:  <!– is HTML syntax, not server-side syntax.  If you want to comment out a server control, use the following syntax:

<%–   <asp:Button . . . . />  –%>

 

Now isn’t that absurd?  Learn how to program in 7 days.  Learn how to program what?  Your VCR?  You’ve seen the books that claim to be able to teach you how to program in a matter of days.  Personally, I’m on the 10-year plan.  Learn how to program in 10 years.  I’m on year number 7, and the more I have learned from the start, the more I learn how much I don’t know.  Really, it’s absurd to even think you can learn how to program in a complete year.  After a year, you may be able to write code that performs a certain task, but do you really know how to program?  Look back on your first year of programming and the quality of code you produced after 1 year.  A WHOLE year of programming.  That’s a long time.  Is it really?  I bet that a lot of you shudder and the work you did after your first year of programming.  I’m on year number 7, and I think I’m on track to know how to program in 10 years.  3 more years to go.  7 years has given me time to learn several languages and actually learn from some mistakes.  Most of all, it’s given me time to learn about maintainability and not just the development phase of a project.

When I talk about programming, it doesn’t matter if it’s .Net or whatever.  Programming is programming.  Every language and platform has function constructs, decision structures, looping constructs, etc.  Programming is programming.  I call myself an experienced .Net programmer, but even the most experienced .Net programmers in the world still don’t have more than 3 years of experience with .Net unless they actually worked on the product itself.  I’ve had this opinion for some time, but when I came across this article from Peter Norvig, I was surprised.  He spells out my points exactly.  You really should have a read.

Whidbey Beta2 change in code behind.

Fritz, explains it much better than I could. 🙂

 

I have developed several web applications with Whidbey Beta 1 including a complete port of a software package of mine from v1.1 to see what changes would be necessary.  There were some significant design differences, but the port wasn’t that painful.  The big change was that the code-behind wasn’t its own class.  It was a partial class that merges with the ASPX at runtime compile.  This model  is changing for Beta 2.  Now, the code-behind will stay a class that the ASPX will inherit FROM, not merge with.  Check out Fritz’s post.  I think this is a change for the better.  There were some issues that arose from the partial-class code file.