Brain dump: Getting VS.net intellisense AND easy deployment with ASP.net

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:

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 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.

 

Bookmark the permalink.

Leave a Reply

Your email address will not be published.