views:

49

answers:

2

can i have some general advice on converting a classic asp site to asp.net? i've never worked with classic asp before and have only worked with asp.net 2.0 for the past 6 months or so, so this is completely new to me.

i noticed that this site i'm wokring on uses a few 'include' files. i know i should probably take the code from the include files and copy them into their own class files. i've notice that there is no code behind file, that each page is written in it's own file (markup and code). also, and this is kind of throwing me off, there are no event handlers. are there any other helpful nuances between classic and .NET you can mention?

one more question: i've notice in each file in my project that there is some code that is written above the markup, and some more below the markup. it seems it would be better if ALL the code was written above or below the markup, for organizational/readability purposes. unless, there's a reason for this. ???

thanks.

+3  A: 

You certainly have a challenge on your hands. As far as comparisons are concerned, MVC is probably closer to classic ASP as it doesn't attempt to abstract the web into an event based structure - but that would just be another thing for you to learn.

Classic ASP is a completely different beast to ASP.NET as you're finding out. Basically each URL resolves to a parent ASP file. That in turn includes other ASP files (they can have different extensions if developer felt like it i.e. ".inc"). These in turn can include other files. It is entirely possible to have the same file included several times - generally ASP engine copes with this however. It is important to remember that all includes are processed to make one big document before any actual ASP processing starts. So once all the includes have been processed, you have one big document. The ASP engine then starts at the top and processes the code line by line. You'll probably have HTML and ASP code all inter-twined, with calls off to proceedures.

If you can program C# or VB then reading an ASP file with that in mind shouldn't be too difficult. At that stage you can begin to tackle the functionality one page at a time. Just remember that in ASP there is also no "post back" or view state concepts. Again this is ASP.NET trying to abstract web programming to represent an event based approach.

Sorry one last thing - some commands such as option explicit in ASP must be the first thing in the parent ASP document, so that must always appear before any other code or markup. After that code and markup can be mixed intogether - resulting in the infamous "tag soup" that ASP will be remembered for.

Paul Hadfield
Everything Paul said is spot on. The only thing I would add is that you shouldn't think of this as a conversion so much as a do over. Instead of trying to translate the classic asp to 2.0 you should try and replicate the functionality and make sure the business logic is the same.
Varuuknahl
+1 And can I add - I guess the comparison to MVC is a bit stretched - but I guess you don't have the controls (and viewstate) out of the box - you need to handle state manually ;) You might also check out http://download.microsoft.com/download/d/4/2/d42dddd5-4444-45f5-850a-4e487d3c03c8/Migrating_ASP_to_ASP_NET_EMEA.ppt
nonnb
A: 

Take your includes and categorize them:

1) Code functions
2) Template functions

All code functions should be dropped into business object classes or modules. The template functions should be placed into user controls and sequently master pages. I strongly suggest the use of master pages in controlling the templated look of your new project as it will save you a lot of time in managing the site and transferring all of the actual page functionality into the new pages.

ASP is a scripted language where as Asp.Net can be either scripted or compiled. I would recommend choosing a Website Project because this will give you the greatest flexibility in deploying the minutae of the code. A Web Application project will compile everything into a singular .dll file which is easy to deploy, but it leads to a lot of regression testing if/when page code intertwines.

Once you have a templated structure, common classes, data access layer and masterpage/usercontrol structure established, it just becomes a task of going page by page and converting it over to the new code.

Joel Etherton