Rob Eberhardt

No not that kind of Brain Dump -- I just figured I'd mention this stuff, in case it comes up again/for someone else...

I've been fighting with ASP.net and Visual Studio.net (2003).   VS.net pushes code-behind files (aspx.vb or aspx.cs) hard, since they help separate logic and presentation (a good thing).  One particular way is by disabling Intellisense (the #A1 best main reason I use VS.net and InterDev before it) in the aspx file itself.  

Next problem:  Ok, I bought into using code-behind file for UI/logic separation.  Unfortunately every little change to the code-behind requires a rebuild, and therefore a restart of the app (logging me out, since I'm using tracking auth in session).  So I then have to re-login and find where I was all over again... for each and every change to the code-behind!

(BTW, contrary to popular misconception, code-behinds don't improve performance.  Well, they're pre-compiled, so they may be faster on the very first page load than inline code [which is compiled on that first load], but afterwards they're identical in speed.)

Alright, screw the code-behind, I think.  back to my own code separation -- one big logic block before the presentation block, with minimal connections between.  Big errors! (something about method body, I recall)  -- I can't put functions/subs there.

My first discovery: you can use functions/procs in the aspx.  You just can't have them inside <% shorthand ASP tags %>-- they only work inside explicit script tags (e.g. <SCRIPT runat="server"></SCRIPT>).  Apparently <%%> and <SCRIPT runat="server"></SCRIPT> are no longer equivalent to each other, as they were in Classic ASP.

SO, my gears turned and came up with a solution to the mess: a homebrew code-behind.  I ripped out the contents of the code-behind, put them in a separate aspx file (inside a <SCRIPT runat="server"></SCRIPT> block), and just include it.  This solves the rebuild/restart problem, and still maintains code separation.

Downside: no Intellisense!  (since VS.net now only enables it for what it recognizes as code-behind files)

Next discovery: The @Page directive can have an src attribute/property to reference the code-behind file (it normally uses Inherits and Codebehind attributes/properties to enable the code-behind).  src does NOT require rebuilding to take effect.  It also works with a normal code-behind files, so you get blessed Intellisense.  (more info here: Inherits vs. Src vs. Codebehind)

So I now have a solution, just with something like <%@ Page Language="vb" src="report.aspx.vb" inherits="report" %>. (The inherits is still needed for object/class references).

One catch: VS.net complains loudly when it loads a page with this src attribute:

It loads fine on the second try, but color-coding on any inline code is then disabled.  (Workaround for that: remove the src and inherits attributes, save, reopen the page and re-add those attributes. All works fine as long as VS.net stays open after that.)  For me, it's a small-enough price to pay for code-separation, easy deployment and Intellisense.  (Microsoft's src info here, but no explanation why VS.net doesn't fully support ASP.net, certainly none why it actively hinder its use). 

Some further, unrelated discoveries:

• Response.IsClientConnected is extremely expensive.  If you need it in a long loop, only check it once every 100 or more records.  Going from every 10 rows to every 100 gave me a 7x speed increase.
• Option Strict -- enforces good coding, since it makes you explicity declare all types and early-bind your objects.  Unfortunately (I think) it also adds a lot more coding for explicit type conversions too (for instance from recordset field values).  It seems the parser checks the type conversions in a second pass, so it may be easy enough to turn it on for the first pass and off again when it starts throwing type conversion complaints.