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.
Related
I have been looking at ASP.Net Web Pages and I think it would be a good replacement for some classic asp sites I am working on. There is a lot about them that is similar to how classic asp did things, so I believe there is a chance I can drag the other programmers into the present. My problem is that I have yet been able to find any indepth documentation to see if there is any "gotchas" I need to be aware of if I choose to go down this path. So if anyone knows of any, I could really use that information. I think going straight to MVC and Web Forms would be a bridge too far for the others at the moment. Thanks.
Wade
I found a link from Mike Brind - should I use WebMatrix to build a real-world website?
I'd suggest that Web Pages as a framework is probably the best next step you can take, but I would also advise that at least one person in the team takes time to understand the basics behind the MVC pattern. You may decide it's too much for the majority of the team at the moment, and that's fair enough, but you can use your knowledge to plan the development of the Web Pages site so that it can be more easily converted to MVC at some stage in the future, should you decide that's the way to go.
The things I would look at (coming from a classic ASP background myself) are functions and helpers. Decide on a data access strategy - The Entity Framework works well with Web Pages and can be transferred to MVC easily. Avoid the Database helper. Use Visual Web Developer 2010 SP1 for the Intellisense option.
As Knox said, you have the whole of the ASP.NET framework available to you so there should be no Web Pages specific "gotchas", and it's a massive step up from classic ASP.
I've been using Webmatrix/WebPages/Razor for a while now and like it. It's been a while since I used Classic ASP, but WebPages to me feels like a true successor to classic asp and what ASP.net should have been from the start. I'm actually moving most of my smaller sites to the WebPages framework from WebForms. Here are some things I've encountered.
I'm not sure if this is a gotcha or not, but I thought I would mention that with WebPages the scope of your variables may behave differently. I know a lot of Classic ASP sites that used to use include files to run snippets of code. Many of them depended on global variables set in the parent document. In WebPages, if you use RenderPage or Helpers to replace includes they run mostly outside of the Parent's scope. If you used Server.Execute instead of includes then you might not notice much difference, but if you did use includes and lots of global variables you may notice it.
Another possible gotcha is in ClassicASP <%=%> doesn't encode output, but in WebPages the Razor syntax # encodes output by default.
Another thing to consider is using C# vs VB.net with Webpages. Although vb.net works you'll find that most samples, tutorials and people in forums use C#.
Finally something that bothers me is that it is named the "webpages" framework. I've found it hard to do a good Google search using the term "webpages". Even "asp.net webpages" brings back mostly webform results. I have more success using "webmatrix" or "razor".
Can't recommend any documentation but here is an introduction to Web Matrix on mikesdotnetting.com blog where he has blogged quite a lot about Web Pages with Web Matrix.
We have two production sites, developed using Web Matrix. One serves our customers, the other is an intranet for our staff. They've been running in production for almost a year. I'd say about 95% of the sites were developed purely in WebMatrix IDE with about 5% going into Visual Studio, especially for the occassional obscure debugging. We're happy with WebMatrix / Web Pages. I didn't use WebForms because I was concerned about WebForm's ability to do really lightweight pages, since many of our users are using cellular data on iPads or iPhones. I didn't use MVC because of the additional complexity, since many of our pages are just showing the user read-only data from our production database. Because WebMatrix gives you access to the complete ASP.NET library, I haven't felt held back at all.
We are currently converting our ASP pages to Web Matrix. We tried to do conversions using WebForms a few years ago, only ending in frustration. After a small learning curve on the C# and Razor syntax, our development staff feel that we made a correct decision in going with Web Matrix.
Which is the best way to convert a .asp page to .aspx? Classic asp to asp.net.
I'm trying to avoid rewriting all the pages from scratch.
Thanks
I think it's a completely different language and you really can't avoid doing everything from scracth. I think that any solution other than starting all over would take just as much time and headache than starting from scratch.
It really depends on a lot of things. Mainly, how complicated the page is, and what it does. You will need to be a little more specific in your question, but there really isn't any single "one shot" solution.
My first shot at asp.net was migrating an asp application and there was and still is no straightforward migration path. The best that we found was so split the application up into functional areas then migrate each area - effectively running two apps with a bridge inbetween.
I always thought that ASP.Net was misnamed as it made it look like an upgrade to classic ASP which really don't believe it is. ASP.Net is more like an attempt to bring windows style programming to the web, abstracting away the stateless nature of the http request - certainly in it's webforms incarnation
If you are determined for a classic ASP style app you could include all the code on one page forgetting the page behind model though that would be unusual. If you can make decisions about the technology used you could consider MVC as conceptually at least it has more in common with ASP than the webforms. MVC admits it's a web app (like ASP) whereas webforms prefer to hide that fact under the covers.
I have a reasonably large project at work that I've inherited. It's an ASP.NET 2005 website project and two C# library projects for data access and some business logic. The code actually runs 6 different database driven websites. It displays different images and text for each site based on logic that examines the URL and uses a series of Web.config values and switch statements.
We now have several new websites that will follow the same pattern and framework as these 6 and so management has decided that we should not reinvent the wheel and we should continue to extend the existing code. While I understand the decision from their perspective, the thought of extending this code with even more Web.config values and even more switch statements throughout feels wrong. It seems like there should be a better way to manage this particular form of complexity, but I don't have a handle on what that better way should be.
At the same time, I've been looking for a project to start learning ASP.NET MVC and I've been leaning towards re-developing this project with it on my own time since it's complex, but the requirements are in the code. I'm looking to gain 3 things out of moving it to MVC: 1) be able to test the app and all it's versions and all it's dark corners that I don't even know exist yet, 2) hopefully find a way to make managing about 12 sites on a single code base manageable and 3) learn MVC.
After rambling a bit, here are some specific questions:
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue? It's a bit hard for me to tell without having a deeper knowledge of MVC.
Is there a templating pattern or framework that I can apply (in either WebForms or MVC) that is suited for sites like these that have similar content and structure and run from the same code base?
Is there a better way than examining the URL to decide which site is being viewed and what the images and text should be displayed for each site?
Thanks for the time. I do appreciate it!
ASP.Net MVC might have some real advantages for you here. You wouldn't be manually examining URL's any more, because the Routing functionality of MVC would do it for you - so in a way, it is a "better way". Here are some advantages:
URL routing is an easy way to differentiate which site was being served, and your "which site am I" parameters would be automatically handed down to every Controller (and subsequently, every View) if you structured your routes correctly.
URL Routing works both ways, so it would be relatively straightforward for you to define a single View for all your sites that generated proper images and script references to whichever site directory you needed.
Partial Views would be a great way to switch in site-specific content in corner cases where the template wasn't exactly the same for each site.
As long as the logic was reasonably similar for each site, ASP.Net MVC 1.0 could handle this. If you need different controller logic for each site, the upcoming release of ASP.Net MVC has the concept of "areas", which would allow you to implement different sites in the same application that all had their own Controller, Model and View directories - but were differentiated by their routes.
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue?
Honestly: I would not go this road. ASP.NET is powerfull enough to have a multitennant system. There are things that help to build multitennant applications in ASP.NET MVC. You have IoC for changing business rules between applications and you have the option to dynamically choose which view to render.
You have testabillity.
Thats all great: read here about it
link so
But still: It is an enourmous effort to implement such a system. ASP.NET is great (you got Routing now!) and if you have a running system better invest your time in making it better.
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 am making a making a new asp.net web forms site and would like to beautify my urls - I want to accept a url like this one "www.mysite.com/1-2,3" and turn it one like this "www.mysite.com/page.aspx?a=1&b=2&c=3". Which option is best for this task - IIS7 Url Rewriting or Routing in terms of performance and ease of maintenance. Btw I am planning to use medium trust shared hosting IIS7, maybe 6.
In the past I used PHP's mod_rewrite, which I was quite happy with, however now this whole site is being translated to ASP.NET, and I don't know which option to pick.
PS - I have already read this and this, however didn't find it clear enough for my problem.
I would make a strong argument for using routing. It keeps the request-resource resolution logic within your application, so it's very easy to add application-dependent logic when you need, and it eliminates the need to maintain synchronization between your application and a separate configuration resource.
Routing works great with traditional webforms.
URL rewriting is often (though not always) a compensation for a problem, rather than a solution - server software and frameworks still built around the older notion of web pages, which represent physical resources. However, web applications should react to requests as commands; but only relatively recent, modern web frameworks have begun to support that model natively. Routing is one of those developments.
I would strongly suggest to use routing,
it will in fact be more integrated with webforms in next version of the framework.
URL rewriting is more of a "hack" due to the lack of the routing in the first place. If you already have a project that you want to "shine up", then url rewriting will do just fine.
But when starting from scratch, I would definitely use routing.
Routing hides you application structure and makes you think more of your urls, as path to the content that you want to show, opposed to the path to some page with params.
And you don't have to keep track of 2 things when changing stuff, like you would with rewriting.
more in this article
IIS 5/6 used ISAPI filtering which was basically the equivalent of mod_rewrite for IIS. I hear that IIS7's url rewriting is a lot easier to manage and configure than ISAPI.
Well it depends on whether you're using classic ASP.Net or the new MVC framework. I don't have any experience with the MVC framework, but it sounds like it supports what you're looking for right out of the box.
On the classic ASP.Net side of things, we're currently using an IIS extension called ISAPI_Rewrite. It behaves similarly to Apache's mod_Rewrite and they have a free version you can use that has most of the power of the paid version ($100).