Here's a strange thing that happened yesterday. An ASP.NET app, written in VB.NET, was only intermittently dealing with its events, such as button clicks. At first it seemed to be that the event was handled if we were debugging, and not handled if we were not. But that turned out not to be the case.
Whenever you're faced with weirdness -- and let's face it, an event that sometimes is handled and sometimes is skipped counts as weirdness -- the knowledge base is your friend. A team member found 314965, which is a C# version of the problem. Although no-one could find a VB KB article, these are our symptoms, and more importantly this fix was a fix.
A control event on a Microsoft Visual C# .NET Web application form may not fire. The event does not fire if you wire the control event imperatively, that is, if you double-click the event from the Events view and then add the code.
Add the event to the HTML code behind the form, that is, wire the control event declaratively.
“Wire the control event declaratively” means put an onxxx= attribute in the HTML:
<asp:Button id="Button1" runat="server" oninit="Button1_Init" Text="Button1"></asp:Button>
Instead of oninit you might have onclick or whatever event you have an issue with. Also, make your handler function public rather than private.
Moral of the story: there are two. First, it isn't always you. I can't tell you how many emails I've received telling me “there must be a bug in Microsoft's C++ optimizer, because my debug builds work beautifully but my release builds blow up.” Experienced C++ programmers mutter or shout “memory problem” when we get such emails: you're overwriting something or leaking or just generally not handling memory well; debug and release builds have huge differences in allocation, initialization, and other memory work when you're using unmanaged C++. Most of the time, it's you. But every once in a while, it's not you. And a quick search through the knowledge base is one way to see if it's you or not. Second, just because you're writing in VB doesn't mean that C# KB articles don't apply to you. Never be a language snob.
ps: of course I program in VB sometimes. What else would I use to create ASP.NET apps?