To correctly reference a style sheet from within a master page in ASP.NET, use the following:


<link rel="stylesheet" href="<%= ResolveUrl("~/css/screen.css") %>" type="text/css" media="screen, projection" />


It’s the ResolveUrl that does the trick.

In .NET 2.0, the old method of getting information from the app.config has been depreciated. The new method is:


ConfigurationManager.ConnectionStrings.Item(YourDB).ConnectionString


For this to work, though, you need to remember to add a reference to System.Configuration. This needs to be done for each project in the solution that uses it. Thankfully I figured out that last bit pretty quickly.

GetLogin might look like this (VB.NET):


Public Function GetLogin(ByVal strLogin As String, ByVal strPassword As String) As Integer
   txtLogin.Text = strLogin.Trim
   txtPassword.Text = strPassword.Trim
   Me.ShowDialog()
   Return mintToken
End Function


In .NET 2.0 and Visual Studio 2005, this causes an exception to pop-up:

LoaderLock was detected

Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

This exception is thrown on the first keystroke of my login form.

This seems to be a common problem, and the solution is to shut off the LoaderLock MDA (Managed Debugging Assistant). This can be done in the menu Debug -> Exceptions -> Managed Debug Assistants and unchecking the LoaderLock option. I don’t like this solution, but it seems to work.

This Microsoft KB Article on LoaderLock contains some good information about this issue. One of the commenters stated they had the same problem with an application throwing this each time a key is pressed, but no one has replied with a reason why. My Visual Studio 2005 project contains a form originally designed in VS 2003. I don’t know if that has something to do with it or not.

Hat tip: chrisB. Also Simon’s Software Stuffp


ListItem listItem;

listItem = new ListItem("No", "0");
DropDown1.Items.Add(listItem);
DropDown2.Items.Add(listItem);
DropDown3.Items.Add(listItem);

listItem = new ListItem("Yes", "1");
DropDown1.Items.Add(listItem);
DropDown2.Items.Add(listItem);
DropDown3.Items.Add(listItem);


Later, I’m loading my values from the database like this:


DropDown1.SelectedValue = data.IsBool1 ? "1" : "0";
DropDown2.SelectedValue = data.IsBool2 ? "1" : "0";
DropDown3.SelectedValue = data.IsBool3 ? "1" : "0";


However, it turns out that when you do it this way, whenever DropDown3 is changed, the same value will be chosen for DropDown1 and DropDown2 as well. ASP.NET keeps track of the ListItem objects by reference.

The correct way to do this should be:


DropDown1.Items.Add(new ListItem("No","0"));
DropDown1.Items.Add(new ListItem("Yes","1"));

DropDown2.Items.Add(new ListItem("No","0"));
DropDown2.Items.Add(new ListItem("Yes","1"));

DropDown2.Items.Add(new ListItem("No","0"));
DropDown2.Items.Add(new ListItem("Yes","1"));


I guess this is technically less lines of code, but I was thinking creating new ListItem objects each time would be less efficient than my original code. Not that a nanosecond will make any perceivable difference.

I guess it’s refactoring time!

By setting the defaultbutton property on a form or – even better – an <ASP:Panel> control, the page automatically handles it for you. Each set of controls which should submit with a certain button can be contained in the panel and everything is hooked up automagically.

One caveat: If you set a default button on a panel but not in the form, other controls seem to use the panel’s default button even when they are not in the panel.

After a conversation with a pair of developers I work with, I have finally been convinced that C# is a better syntax than VB.NET. That’s saying something, considering I used to believe I liked my languages verbose. You know, like COBOL. There were three things in the C-based syntax of the language that bothered me:

• Case sensitivity
• Curly braces
• Semicolons

Like me, one developer was a former VB programmer now a fan of C#. The other was more of an open source proponent, but extremely knowledgeable about programming theory and history. A discussion with these two and some time actually developing in C# helped me understand the power of the language and the benefits over VB.NET syntax. I would still like to point out that the IDE in Visual Studio could use a few more features to truly make C# programming outstanding. I guess Resharper will have to fill the gap.

Case sensitivity

For the longest time, I could not come up with a decent reason for a case sensitive language. In VB.NET’s case-insensitive world, the IDE can auto correct your tYpInG mistakes very easily. It isn’t as easy to do in a case-sensitive language, because the IDE will not know “var” verses “Var” verses “VAR” when all three are in use. I have found case-sensitivity to make sense in naming variables, especially in the post Hungarian Notation world. I can declare a variable and name it the same as the class on which it is based. For example:

Customer customer = new Customer();

I don’t have to spend any time coming up with a different variable name. It actually requires less thinking. Less thinking is good.

Curly Braces

My previous experience with C-based languages was in college, circa 1994. Back then, there were no fancy IDEs, we coded in a text editor and we liked it that way!

Ok, I didn’t.

Formatting a document was a giant pain, but I had to do it to my curly braces straight. With VB’s If.. End If structure, I could read where the end of a statement was without tracing back and forth. Admittedly, Visual Studio can be thanked for fixing a lot of this issue in C#. It will auto-format a document for you and highlights bracket pairs. A number of other IDEs have done this for c-based languages as well.

What I hadn’t realized was how symbology makes it easier to understand the code. By using curly braces and other short constructs that are not words, C-based languages become easier to understand. My mind spends less time translating the code when I read it because the braces fade into the background. I can focus on the important things instead – the actual code.

It actually requires less thinking, and less thinking is good.

Semicolons

This one is more of a religious debate than anything else. I used to prefer not having to end statements with a semi-colon, choosing instead to use a line delimiter for continuation. That worked out fine and dandy until I needed to reformat a line – it involved moving the delimiters. In C# I hit enter and I’m done.

You know… less thinking.

I thought I would use a hyperlink with a call to javascript that toggles the display of a <div>. It seemed like the best solution within the context of the existing page.

With that in mind, I added some javascript to my ASP.NET page (using RegisterClientScriptBlock) without a problem. But when it came to adding the “more” link and the show/hide div, I ran into a serious issue.

What I really wanted to do in the repeater’s ItemTemplate was:
<ItemTemplate>
<a href="javascript:toggleDisplay('<%=pnlMoreLinks.ClientID%>');">show / hide</a>
<asp:Panel runat="server" ID="pnlMoreLinks" CssClass="morelinks">
Show and hide me!
</asp:Panel>
<ItemTemplate>

My thought was that it would render code to the browser along the lines of:
<a href="javascript:toggleDisplay( 'ctl00_ContentPage_Repeater_ctl01_pnlMoreLinks');">show / hide</a>
<div id="ctl00_ContentPage_Repeater_ctl01_pnlMoreLinks" class="moreLinks">
Show and hide me!
</div>

The problem is that causes a compile error:
The name 'pnlMoreLinks' does not exist in the current context

Not good. Outside of the repeater, the <%=pnlMoreLinks.ClientID%> works beautifully. Inside the repeater: compile error. It seems the reference to the asp:panel is not available to other controls in the designer. In case you were wondering, proximity had no effect either.

A quick check with the other smart people led to no real epiphanies though the designer. In the end, I manually set the reference in the link to the ClientID of the panel through the ItemDataBound event on the repeater. In the code behind, this method lets you control the formatting of each row as its being rendered. The ClientID of the panel is available at this point of the page’s life cycle.

protected void rptSearchResults_ItemDataBound(object sender, RepeaterItemEventArgs e) {
   HyperLink link = (HyperLink)e.Item.FindControl("lnkMoreLinks");
   Panel panel = (Panel)e.Item.FindControl("pnlMoreLinks");
   if (panel != null && link != null)
      link.NavigateUrl = "javascript:toggleDisplay('" + panel.ClientID + "');";
}

The repeater’s ItemDataBound method has been invaluable to me in a few other tasks… having more control of the repeater than is provided by the designer and data binding is essential to usable, well-built web apps.

And now I have a hide-able div in a repeater control. Sweet.

This week’s adventure happened because the client upgraded their machine to Service Pack 2 of Windows XP.  Most in the tech industry know it was rolled out to curb zombie PCs.  So the firewall and nearly everything else was closed down.  Without being told about the upgrade, I was at the client site trying to figure out what was wrong.

Fixing the problem was relatively simple once I Googled DCOM changes in SP2.  In fact, I even found an article on the OPC Foundation’s website on Using OPC via DCOM with Windows XP Service Pack 2 (direct link to the .pdf).

(Hat tip to Professor Z.)

If you have a dropdownlist in ASP.NET:

<asp:dropdownlist id="states" runat="server">

If this dropdownlist is databound:

DataSet ds = new DataSet();
ds.ReadXml(Server.MapPath("states.xml"));
states.DataSource = ds;
states.DataBind();

...and you want to add a blank value to ensure the user has selected a value, do the following:

states.Items.Insert(0,"");

You can substitute any value for the blank string, such as "--select--".

In 2000, when I first set up this website, I decided I would write my own app to add posts to the front page. These became known as Spectacularities. I’m not sure that at the time the word “blog” even existed. It certainly hadn’t caught on by that point if it did. Essentially, I was building software for blogging.

I wrote a quick little utility to add Spectacularities to the home page. It consisted of a user control for displaying the page, a single form for post entry, and one database table. It was enough to get things working that day and I was happily on my way. I never intended for my little blogging app to stay as small as it was. I never intended for it to end up as decrepit as it did.

For reasons I can’t remember at the moment, the admin page eventually fell into disuse. Something broke and I just never fixed it. It may have been right around the time .NET arrived and I never upgraded the page. I switched instead to using the stored procedure directly in Query Analyzer to add and update my posts. It was a lot of single quote manipulation and generally a pain in the rear.

Then the archive page, built using the said user control, began to get out of hand. When three years of posts began to appear on it the load time was unbearable. I took the archive offline.

With just the current post displayed and a propped up SP, things really began to go downhill. I posted less and less frequently. Finally, at the end of 2004, I put Uhri.com out of its misery. The whole site got replaced by a single flatline graphic. It was a sabbatical which lasted almost an entire year.

In September of 2005 I approached the problem with new vigor. I came up with a new strategy for my own blogging software, tenatively dubbed “uBlog” (I thought it was a clever name, anyway). I started the “very public” redesign of the site with requirements gathering and everything. I put up use cases and details about how the site would be designed. It was all part of my grand plan to write an XHTML and CSS-based blogging software in ASP.NET.

I started checking out the other blogging tools out there. WordPress had caught my attention on several occasions because of its standards compliance. I reviewed dasBlog, .Text and its fork SubText, and a newcomer to the .NET blogging tools, VineType. VineType seemed to be the most promising — a .NET-based blogging tool with XHTML standards. I may still consider VineType in the future as their codebase grows. The developers there seem to have a good thing started and while it may not grow to the size of WordPress, they do provide the basis of a good blogging system in ASP.NET.

As I reviewed these competitors, I came to a sinking realization.

I had NIH Syndrome. I wanted to create my own tool with features the way I wanted them. I saw the thriving WordPress community and was jealous. There were plug-ins for anything feature I could possible want. With the exception of VineType, the .NET blogging tools looked like garbage. If I were to roll my own, I could make it as easy and beatiful as WordPress. But if I built my own software, I could never reach the critical mass of WordPress. There wouldn’t be a community of developers building add-ins that would make a great .NET blogging application. There just aren’t enough bloggers in the .NET world that would care.

I wust wasn’t sure I was ready for the kind of commitment involved in something that would most likely be unsuccessful.
Joel probably said it best:

If it’s a core business function — do it yourself, no matter what.

As a corrollary, if it’s not a core business function, outsource it.
It turns out blogging software isn’t a core business function. Its not what I want to spend my free time doing. I’m much more interested in the creation of content. That’s what the blogging software is for, after all. I’d be crazy to reinvent the wheel just to call it uWheel (hey, another catchy name).
So I installed WordPress and haven’t looked back.