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.
