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.
Related
I've built several database driven web sites with ASP and I'm trying to migrate the basic functionality to an ASP.NET architecture.
I want to have each link in my navigation tree correspond to a different function that will step a user through various requests and provide sequential database driven responses and possible follow-up questions. I typically do this in ASP by using the query string to execute different parts of the code in an SSI file. Each link in my navigation tree basically calls a different SSI file.
In ASP.NET I think I have a pretty good handle on web form basics, data binding, site navigation tools and master pages, but I'm having trouble with the overall design picture.
Do I want to have each link redirecting the user to different pages? My understanding is that ASP.NET is much better at maintaining state information and so I shouldn't have to rely on the query string to keep passing values to an SSI file to do sequential parts of each task.
Should I be using BLL and DAL to do this and/or stored procedures and managed code? Or could I do this sort of thing more simply with ASP.NET web pages, as opposed to web forms?
Feedback that would include a reference article and/or web example would be greatly appreciated. Thanks!
You don't necessarily have to abandon your whole way of thinking and take up ASP.NET Web Forms.
I've been making sites with ASP.NET Web Forms since it came out in 2001. But I think ASP.NET MVC would be an easier transition for you. I mean, some things are more difficult in MVC than in Web Forms. But on the whole, MVC will promote more web friendly practices and it's what I prefer now.
For example, the whole idea of postbacks and viewstate in Web Forms certainly makes a lot of things easier. But they also have a problem of hurting SEO and breaking the back button. MVC doesn't rely on any of this and it's easier to refine the user experience with the way form posts, redirects, and URLs are handled.
I wrote an article awhile back comparing MVC vs Web Forms...
http://swortham.blogspot.com/2009/10/when-to-use-aspnet-web-forms-and-when.html
Based on what I'm seeing, it looks like you've got wizard-style navigation across multiple ASP pages, and you want to have wizard-style navigation in an ASP.NET (WebForms not MVC) site.
If I'm misunderstanding this, I'll gladly delete this answer.
I'd recommend the Wizard control, (Video demos available all over the place) which will provide such an interface in one page, reducing a lot of the complexity. there's no need to keep track of variables across pages - it's all in one page, and therefore always accessible.
Wizard pages do tend to have a LOT of code and markup, but the trade-off is that all of the wizard functionality is in one pace, not scattered across files, and it's inherently obvious what's happening at each step. With the multiple-file approach, a maintenance developer needs to trace which page posts to which page and spend more time understanding the design.
The article on MVC vs Web Forms was quite interesting, although after looking at a few training videos I got the impression that the coding is quite a bit different from ASP. (Most of the examples I also see involve C#, although I have seen a few with VB, which is preferred since I'm already learning a lot of new things in a short time.) Also, I wonder if MVC will let me use the validation tools, which will be quite necessary in a different aspect of this project that involves several different and quite long forms. Given that I've invested a fair amount of time in learning about ASP.NET, I'm wondering if I should just go the extra mile (or two) and learn how to create business objects (BLL) and a data layer (DAL).
Creating a new version of a classic asp (vbscript) site in ASP.NET MVC. Users will have the option to use either the new site or the old one. Both will run side by side.
Old legacy vbscript classic ASP site has no separation between logic and UI, thus making it impossible to rewrite properly. Tens-of-thousands of lines of Response.Write's and nearly every inline sql call consists of at LEAST an update/insert/delete/select... all within the same string.
I'm in a time crunch. Instead of trying to reverse engineer this nightmare, when I need certain functionality in the new MVC site, I simply make a call to the corresponding old classic asp page via jQuery or the Html Agility Pack. I'm trying to consolidate the number of steps in a process within the MVC site, so /StepA (MVC) would call /step1.asp, /step2.asp, and step3.asp of the classic site.
It works, but it makes me feel dirty... like a two dollar hooker. Has anyone else done something similar?
it depends on your old code and how it makes easy. would wish to create it the site from scratch if time permits because that would helpful in future changes
Bite the bullet and rewrite. This is going to be a performance and maintenance nightmare that will likely end up being more expensive than a pre-emptive rewrite. If this is a 1:1 sort of rewrite, cheap offshoring could be a great option, given the template of the existing site and functionality to serve as a spec.
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.
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.
Background:
I am an intermediate web app developer working on the .Net Platform. Most of my work has been defined pretty well for me by my peers or superiors and I have no problem following instructions and getting the job done.
The task at hand:
I was recently asked by an old friend to redo his web app from scratch. His app is extremely antiquated and he is getting overwhelmed by it breaking all the time. The app in question is an inventory / CRM application and currently each customer requires a new install of the app (usually accomplished by deploying it on a different domain on the same server and pointing to a new database).
Currently if any client wants any modifications to the forms such as additional fields, new features, etc my friend goes in and manually adds those fields to the forms, scripts, database etc. As a result all installs of this application are unique. There is no one singular source repository and no one single version of this app. Generally new features are overtime rolled into the other sites, but still this is done on an individual site by site basis.
I will be approaching this on a very modular basis. Initially I will be coding a module that will query an external web service for some data, display and store it, and periodically update it automatically. The next module will likely be for storing and displaying inventory data. This way I want to over time duplicate the current feature set of his app 100% but do it incrementally.
The Million Dollar Questions
I want to make the app have user
configurable form fields. The user
should be able to go to an admin
page, create a new forms page of a
certain category, and then specify
what fields he wants in there. He
could say 'create a new text field
called Item # and make it a
requirement" and that will get
stored somewhere. All forms will be
dynamically rendered to screen based
on what the user has configured. Is
this a good way to go about the
problem of having no idea what a
customer could want in a form? and
thus be able to store and display
form data of any sort ? What sort of
design pattern should I follow here?
I am familiar with asp.net and
the .net framework in general and
have decent knowledge of javascript,
html, silverlight, jquery, c# etc
etc. I can work my way around web
apps in a good way, but I am not
sure what sort of framework or tech
I should use to accomplish this
task. Would ASP.net 3.5 webforms be
the way to go? or should I look into
ASP.NET MVC? Do I use jquery and ajax for
complete decoupling of frontend and
backend ? or will a normal asp.net
page with some spattering of ajax
thrown in working with a codebehind
be the order of the day?
Just looking for general advice before I start.
I am currently thinking of using ASP.NET 3.5 webforms, jquery for clientside animation, ui, manipulation and data validation, and sqlserver + a .net or wcf webservice for backend.
Your advice is much appreciated as always.
I've recently implemented a white-label ecommerce system for an insurance company that allowed each partner to choose their own set of input fields, screens, and order the flow of the application to suit their individual needs.
Although it wasn't rocket science, it added complexity and increased development time.
Consider the user configuration aspect very carefully In hindsight both my client and their clients in turn, would have been happy with a more rigid system.
As for the tech side of your question, I developed my project in VS2005, using asp.net webforms and webservices with a SQLserver back end, so the stack that you're looking at is definitely capable of delivering a working product. ASP.net MVC will almost certainly help as far as testability goes.
The biggest thing I would change now if I was going to start again would be to replace the intermediate webservices with message based services using nServiceBus, MassTransit or the like. While the webservices worked fine, message based communication should be quicker and more reliable.
Finally, before you start to code, make sure that you understand the current system's functionality inside and out. If the new system doesn't do something that the old system did, it will be pretty obvious to the end users straight away.