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.
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.
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.
Related
I have some software that currently generates a series of files - one of them a relatively simple PHP file. (Not using OOP, PEAR or anything but builtin functions that exist across many PHP versions.)
I have some customers that also use ASP and ASP.Net - I never actually used any of those languages, but looking at it, I think most of the PHP code could be translated directly to classic ASP code...
However - can anyone point me to sources on how to best generate code that will execute/run on both classic ASP and new ASP.NET IIS/similar servers? Can ASP.Net execute ASP/vbscript .asp files? So if for instance I have an ASP.Net page that goes about its normal business - can that include/execute my generated classic ASP file that outputs content?
I preferably want to create a solution that is as easy as possible for me to maintain - but also as easy to use as possible by my customers.
I would like to know what, why or when it is better to choose cshtml and what, why or when it is better to choose aspx technologies? What are these two technologies intended for?
Thank you,
As other people have answered, .cshtml (or .vbhtml if that's your flavor) provides a handler-mapping to load the MVC engine. The .aspx extension simply loads the aspnet_isapi.dll that performs the compile and serves up web forms. The difference in the handler mapping is simply a method of allowing the two to co-exist on the same server allowing both MVC applications and WebForms applications to live under a common root.
This allows http://www.mydomain.com/MyMVCApplication to be valid and served with MVC rules along with http://www.mydomain.com/MyWebFormsApplication to be valid as a standard web form.
Edit:
As for the difference in the technologies, the MVC (Razor) templating framework is intended to return .Net pages to a more RESTful "web-based" platform of templated views separating the code logic between the model (business/data objects), the view (what the user sees) and the controllers (the connection between the two). The WebForms model (aspx) was an attempt by Microsoft to use complex javascript embedding to simulate a more stateful application similar to a WinForms application complete with events and a page lifecycle that would be capable of retaining its own state from page to page.
The choice to use one or the other is always going to be a contentious one because there are arguments for and against both systems. I for one like the simplicity in the MVC architecture (though routing is anything but simple) and the ease of the Razor syntax. I feel the WebForms architecture is just too heavy to be an effective web platform. That being said, there are a lot of instances where the WebForms framework provides a very succinct and usable model with a rich event structure that is well defined. It all boils down to the needs of the application and the preferences of those building it.
Razor is a view engine for ASP.NET MVC, and also a template engine. Razor code and ASP.NET inline code (code mixed with markup) both get compiled first and get turned into a temporary assembly before being executed. Thus, just like C# and VB.NET both compile to IL which makes them interchangable, Razor and Inline code are both interchangable.
Therefore, it's more a matter of style and interest. I'm more comfortable with razor, rather than ASP.NET inline code, that is, I prefer Razor (cshtml) pages to .aspx pages.
Imagine that you want to get a Human class, and render it. In cshtml files you write:
<div>Name is #Model.Name</div>
While in aspx files you write:
<div>Name is <%= Human.Name %></div>
As you can see, # sign of razor makes mixing code and markup much easier.
While the syntax is certainly different between Razor (.cshtml/.vbhtml) and WebForms (.aspx/.ascx), (Razor's being the more concise and modern of the two), nobody has mentioned that while both can be used as View Engines / Templating Engines, traditional ASP.NET Web Forms controls can be used on any .aspx or .ascx files, (even in cohesion with an MVC architecture).
This is relevant in situations where long standing solutions to a problem have been established and packaged into a pluggable component (e.g. a large-file uploading control) and you want to use it in an MVC site. With Razor, you can't do this. However, you can execute all of the same backend-processing that you would use with a traditional ASP.NET architecture with a Web Form view.
Furthermore, ASP.NET web forms views can have Code-Behind files, which allows embedding logic into a separate file that is compiled together with the view. While the software development community is growing to be see tightly coupled architectures and the Smart Client pattern as bad practice, it used to be the main way of doing things and is still very much possible with .aspx/.ascx files. Razor, intentionally, has no such quality.
Cshtml files are the ones used by Razor and as stated as answer for this question, their main advantage is that they can be rendered inside unit tests. The various answers to this other topic will bring a lot of other interesting points.
I think many of us used to face the same question: what's the best practice to port existing web forms App to MVC. The situation for me is that we'll support both web forms and MVC at the same time. It means, we create new features in MVC, while maintaining legacy pages in web forms, and they're all in a same project.
The point is: we want to keep the DRY (do not repeat yourself) principle and reduce duplicate code as much as possible. The ASPX page is not a problem as we only create new features in MVC, but there're still some shared components we want to re-use the both new / legacy pages:
Master page
UserControl
The question here is: Is that possible to create a common master page / usercontrol that could be used for both web forms and MVC? I know that ViewMasterPage inherits from MasterPage and ViewUserControl inherits from UserControl, so it's maybe OK to let both web forms and MVC ASPX page refer to the MVC version. I did some testing and found sometimes it generates errors during the rendering of usercontrols.
Any idea / experience you can share with me? Very appreciate to it.
Background:
This UI project has been created for years and there're 20+ people working on that. Before I start the common master page trial, there're about 50+ web forms pages and only one MVC page. We create new features on MVC, but the old pages keep remaining in web forms.
This situation will keep for a long time, probably because this's a business-driven company so new features are always in a higher priority. This means we need to support both at the same time.
There are several integration problems using ASP.NET MVC master page with web forms pages and user controls. Since the execution pipelines of the two frameworks are not exactly the same it is normal to have some problems.
One of the things I've faced is that web forms uses single interface pattern (it has one <form> tag with runat="server" on the page). In your master page or pages using it you'll have to create this tag yourself if you want to use server controls. Note that this will work for read-only controls. If you need post-back & event handling you'll probably face more problems with event handling and event validation.
Also one trick is to create html helpers that render existing controls to string. You can check this out for more info http://www.abadjimarinov.net/blog/2009/10/29/HowToRenderAspdotNETControlToString.xhtml This is also a partial solution as it will not work with most user controls.
It will be helpful to provide some code or error messages so I can give you more concrete answers. At this level I can only say that the two frameworks are compatible and you can integrate them but this will not be painless and will require some changes in the existing code.
Let me use an analogy
This will sound harsh but will make it easier for me to pass the idea across. Exaggeration helps sometimes because it emphasizes certain things that need to be understood.
Ok. We're using bicycles to get from A to B at the moment. We're considering buying a car but we want to make transition from one to the other as painful as possible. Consider the fact that we enhanced our bike so it uses custom pedals etc. Is it possible that we use these pedals and other enhancements with the new car we're considering?
Essentially it's possible. But without making a huge mess out of it it is definitely not advisable.
Suggested transition is to change pages one by one to use the new technology (new ones of course in the new technology) and not to introduce some MVC functionality to a webforms page. Either MVC or WebForms for a particular user process. Majority of non-UI code can be reused (business services, data access layer code, data/domain model when applicable). But if you're cramming all the code in your code-behinds... Well bad luck for you. If you haven't separated your code you will more or less be repeating code. Unfortunately that's not Asp.net MVC's fault. It's your bad design without SoC.
Don't combine/mix/blend two UI technologies if you're not suicidal. You can go from A->B using either bike or car, but not both at the same time. This means you can have WebForms part of your application and MVC part of it, but not likely on the same page. And this is only possible if you use Web applications not Web sites. Asp.net MVC can't work as a Web site (on demand partial per page compilation).
Re-usability related to my analogy
Bike and car are two UI technologies. What you do or the purpose of you taking the route from A->B is not important. That's business logic. If you're delivering newspapers that's not related to transport. So you can see that other layers can be reused.
Asp.net WebForms vs. MVC
Asp.net WebForms
Server-side controls (web/user) use the event pipeline execution model. Hence they (unless completely presentational nature) have server side events that some code subscribes to. Platform is completely state-full and everything executes in a manner that abstracts the HTTP completely away. Everything looks like you'd be running a desktop application.
Controls usually encapsulate presentation, code (as in server-side and client side script) and style (as in CSS). That's why it's a lot harder to have SoC using WebForms.
Asp.net MVC
This platforms is completely suited for the stateless nature of the HTTP protocol. Every request is completely stateless (unless you store some state data in persistent medium - Session, DB, etc.). There's nothing like an event model. It's basically just presentation of data/information that is able to transfer data to the server (either as GET, POST, DELETE, PUT...). Server side doesn't have any events. It's only able to read that data and act upon it. And return some result (HTML, Script, JSON, ...). No events. No state. No complex abstractions.
Asp.net MVC abstracts away some common scenarios that are related to data. Like automatic conversion to complex object instances and data validation. Everything else is gone.
Asp.net MVC using WebForms
In case you would like to use server-side controls in an MVC application you would be able to put them in your ASPX/ASCX, but they would only be used as pure presentation. You'd provide some data to render. And that's pretty much it. Postbacks wouldn't even work (unless you'd put a submit button on it), because there's no __doPostback client side functionality that would make a POST request to the server. So if there's any server side code that these controls have (even when they didn't initiate a postback) and are related to it's state-full lifetime after they've been loaded, you can say goodbye to them. More or less.
Other than that, you can read a lot about differences between Asp.net WebForms and Asp.net MVC on the internet.
Sharing MasterPages: see this thread.
User Controls:
This is one of the banes of my existence with MVC; in MVC2 and previous revs, there's no direct equivalent to webforms user controls. A sort-of workaround is creating HtmlHelpers - (effectively extension methods to the Html object available in views that return HTML), but that means you'll have to render your HTML in code. Teh suck.
With MVC3 and the Razor view engine, a new class of Html Helpers is available that provides most of the benefits of user controls, including the ability to place them in separate assemblies (and therefore can be used in multiple projects). I'll see if I can dig up an example link, but Scott Guthrie's blog had an example in one of his recent MVC3/Razor posts.
You can do a certain amount of integration between the 2, but you end up with something more complex & less satisfactory from either approach. A comprise in other words.
I've had this same problem in the past & server side includes worked for me. Old school I know & not something I'd generally recommend. But we don't work in an ideal world.
Is it possible to use an ASP page with a master page in ASP.NET?
Unfortunately, not programatically. The closest you could get would be creating a .NET master page and web form, and then embedding your classic asp page via an iFrame.
Are you still having this issue? There is a really old tool to help convert to the early version of .ASP. Unfortunately, I don't believe this is the best practice to convert to the later versions of asp.net. I am working on a project to convert a classic ASP app, with many, many, pages and it is still using recordsets with an old SQL database. I have found that taking each page's "view source" results and creating a new page inside my VS2010, web project, using a master page to help keep the results consistent across the site works pretty good.
The only issue is that this is very tedious and requires frequent testing to insure the page is consistent with the old page.
Back to the original issue of using Classic ASP in a new ASP.net app, I believe the issue may be resolved by having two application pools, and two applications separate apps on the web server, and referencing the old pages as a link in an iframe. Just a thought...
Cheers
I don't think so. Are you talking about classic asp? I just found this discussion.
[Edit]
Maybe you can. Check this out.
[/edit]
I recommend creating a new ASP.NET MVC (as opposed to WebForms) project and converting all your ASP pages into ASP.NET in a single exercise.
Performing a phased conversion and running a mix of ASP and ASP.NET will cause you sorts of headaches and, although it may be perceived to deliver more quickly, the total cost is likely to be higher than a one-off conversion exercise.
ASP.NET MVC lends itself to conversion from ASP far more nicely than ASP.NET WebForms in most cases.
You can use master page in asp.net mvc as a shared resource.
I am having this problem at the moment. Some of the ASP pages are so complex that changes to the site's functionality are way more important than porting some of the more difficult pages.
If you have to work side by side for the time being, slowing moving them over do the following.
Get your business logic in a .NET assembly, "tlbimp.exe" it so it can interop with ASP and then move your page decisions to communicate with this component. This way you can now share business logic and therefore only have the UI data to move.
Pass Session/QueryString data via the DB, not by query string. This means that you should commit your Session/QueryString data to XML or Key/Value pair and store it in the DB (with an expiry time). Then redirect to your ASP with a GUID. There is a potential for someone to hijack the session by grabbing a previous GUID. Therefore have a scheduled job run regularly to clear out session data older than 1 minute.
When transferring to/from .NET, try and make the pages perform their operations before transferring across boundaries. This way the pages can be ported easier. For example lets say .NET displays the order and ASP does the search for a product & adds it to your shopping basket. Make sure that the operations are separate, instead of passing the product across via query string parameters. This way you can then do something like redirect to the order page via query string parameters - http://...../Order.aspx?id= (so long as your user has permission to view the order).
Make sure your ASP code is using stored procedures and not inline SQL as this means code reuse is easier.
I have found creating a dedicated redirect.asp and Redirect.aspx pages are useful as you can see the data passing across the boundaries - its easier for debugging but you'll hear lots of clicks as a user ASP -> ASP_REDIRECT -> ASP.NET_REDIRECT -> ASP.NET.
Globalization is a major problem and has caused problems with our users. Changing a language and redirecting to/from the site in ASP has sometimes caused their language to default to English - and English to Chinese!
There aren't really many ways to ease the transitions, its mainly a case of getting your head down and changing those pages.
I'm looking for an article that will dive deep into how ASP.NET works and how it renders controls from XML markup. For example, under the hood, how does ASP.NET take the following markup and have it produce the results we see?
<asp:Label ID="MyLabel"><%= myObject.Text%></asp:Label>
Does anybody know of any article that will dive deep into the inner workings of ASP.NET?
What happens "under the hood" is that each ASP.NET page is compiled into a .NET class, just like any other. Controls (ASCX) are compiled the same way. There is a compiler for ASP.NET markup just like there is a compiler for c# and VB.NET - you can think of the ASP.NET markup as "yet another" language which compiles to native MSIL.
The native ASP.NET markup is handled by the PageParser. You may notice this class has one interesting and very useful method - GetCompiledPageInstance. As it implies, it compiles the page to a native .NET class. This can be overridden (e.g., you could come up with your own markup and write your own parser/compiler). Spark is a popular alternative to ASP.NET markup.
Each class ultimately inherits from Page or Control. Both of these classes have Render() methods which, at the end of the class's executing its custom functionality you have implemented, write HTML to an output stream.
The big difference is that the compilation often happens at a much different time than the c# or VB.NET code. This is not really a technical requirement so much as it is a feature that permits decoupling the presentation .NET language from the functional .NET language. ASPX and ASCX pages are compiled by the ASP.NET runtime when they are requested in the context of a web server. The compiled assemblies are then held in memory until a) the web application shuts down or b) a filesystem change is detected in one of the ASPX files, triggering a recompile.
It is possible to compile your ASPX pages alongside your c#/VB.NET/whatever, so you can deploy the entire application as a single assembly. This has two advantages - one, the obvious ease of deploying a single DLL. Second, it eliminates the LOOOONG wait time that so often accompanies a "first hit" to an ASP.NET web application. Since all the pages are precompiled, the assembly simply needs to be loaded into memory upon first request, instead of compiling each file.
Reflector -> Expand System.Web.UI -> PageParser Class -> decompile -> Enjoy
(Sorry, not trying to be snarky; this is the only way I was able to get a grasp of it myself)
I always like this site...
https://web.archive.org/web/20210304122759/https://www.4guysfromrolla.com/articles/050504-1.aspx (overview)
https://web.archive.org/web/20210411013534/http://www.4guysfromrolla.com/articles/011404-1.aspx (more in-depth)
I need a LMBTFY (Let me Bing that for you). ;P
Anyway, here are some pages:
Compilation and Deployment in ASP.NET 2.0
Inside the ASP.NET 2.0 Code Compilation Model