Brain dump: Getting intellisense AND easy deployment with

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 and Visual (2003). 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 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 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: complains loudly when it loads a page with this src attribute:

The file could not be loaded into the Web Forms designer.  Please correct the following error and then try loading it again:

The @ Page or @ Control directive contains a src= attribute, which is not supported in Visual Studio.

Make sure all of the classes used in the page are built or referenced in the project.   Click Help for more information.

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 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 doesn’t fully support, 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.


SBS 2003

Yeehaw. Having fun with my first migration to Small Business Server 2003. I’ve used and experimented with it a bit, but not actually done a migration.

It wasn’t until today that I noticed something about it (and this probably applies to Windows 2003 in general). There are a lot of annoying old GUI defaults that they’ve fixed. Off the top of my head: Windows Explorer’s “Hide extensions for known file types” is now off by default, and the default item view is now “Details” instead of “Icons”. (“Simple folder view” IS still on, but hey, every little bit helps.)

SBS’s Internet Explorer could still use some default GUI improvements. I’m particularly annoyed by the huge-by-default “Media” toolbar button. This should always go away, and “Font Size” and “Full Screen” should take its place. (Interestingly, the Media button disappeared from IE with XPSP2. Hopefully the same will happen w/SP1 for SBS2003).

Something strange is going on. Twice now I’ve rebooted only to have video disappear. I even switched monitors. It seemed like jiggling the vid card fixed it, but it hasn’t worked this second time.

Grr. I’ll save it for tomorrow…

Well, I opened the case (a joyously easy Dell case) and found the video card loose.  Reseating it fixed the video.  But it’s happened again now, and reseating isn’t working.  In fact, I think it isn’t booting.  This is very bad!

Update 2:
It was bad memory.  I basically amputated one component at a time, and it started booting again when I got to the RAM (last thing of course).  One DIMM good, the other bad — just like that.   Dell’s making it all good tho: two replacements by Friday 9am.  Support contracts are a nice thing…