Partager via

Migrating from ASP to ASP.NET gotchas.....

  • Article

A couple of the more general gotchas come to mind:

  • ASP and ASP.NET cannot share session state which makes the partial migration of applications using that service very difficult (or requiring a kludge of some kind)
  • No more render blocks - in classic ASP it was common to use render functions due to the top-down nature of the page processing. ASP.NET, of course, uses an event model so at a minimum your render blocks will need to be modified.

That is but just two gotchas that popped into my head when I made this post and I know there are many more. I'm looking for some “real world” gotchas or stories that can be shared with the development community at large. If you got em then please share em!

Comments

  • Anonymous
    August 25, 2003
    When I began moving our site to ASP.NET, it just was too unbearable to simply "upgrade" the code. Almost everything had changed.

    The whole presentation side of things was rewrote from the ground up. I simply started running pages to get the HTML and copied and pastied those for starting points on the new webforms.


    I ran some of the dlls through the upgrade wizard, which worked great. But then I set out rewriting the DAL to take advantage of ADO.NET.


    Pretty much all that remained were the names of functions :)
  • Anonymous
    August 25, 2003
    A few thoughts/gotchas:

    - Complex rendering functions translate easily into ASP.NET user controls, or custom controls compiled to DLLs if you don't mind escaping the HTML and using Response.Write().

    - Simple rendering functions translate easily into Response.Write calls with escaped quotes.

    - You can't declare a page-scope variable and initilize it to any value based on the request, servervariables, session, application, cache, etc. You must declare the variable, then initialize its value in one of the event functions (I believe Page_Load may be the first where System.Web.HttpContext.Current is available, can't remember).

    - Not everyone is using the the ASP.NET event-based form elements, "<form runar="server">" stuff, etc. I prefer to avoid postbacks/viewstates and just handle page views in an ASP-like manner--seems more natural and flexible to me than the convoluted mess some people make out of it.

    - Using code-behinds is useless separation in many cases, IMHO. Layer separation is supposed to be able the ability to replace one layer or the other transparently or have different people editing them. Having a pair of ".aspx" and ".vb" files for every page is a waste of time if you don't need those benefits.
  • Anonymous
    September 04, 2003
    I do a bit of consulting work for independent consultants, and many of these consultants I work with work on smaller projects. These independent consultants oftentimes take a somewhat sloppy approach and, IMHO, overuse session variables. This makes this a real headache when porting ASP to ASP.NET Web pages. Oftentimes, these folks want to, say, create all new pages using ASP.NET, but don't want to take the time to port over their old pages. Since these new pages can't share session state with the old ones (easily), this inhibits these folks I work with. Too bad MS didn't make some tool to aid to adjust ASP pages so that they worked with some third-party COM session state class that used a backing store that the ASP.NET session state could then tap in to.
  • Anonymous
    September 14, 2003
    If you're migrating a bit at a time, you'll end up with both asp and aspx pages running. The way that Querystring encoding works is different in each one. We had to write our own asp compatible Querystring en/decoding functions until we get all our pages ported.
  • Anonymous
    November 01, 2003
    We have at tool at Immunicode.com I would love to hear any feedbacks from developers.