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.
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.
I was recently asked to create a web page using a static website generator, like Jekyll. My question is this:
How does this differ from just creating a website using HTML or writing the page as an ASP.net project in Visual Studio?
How does it work on the server?
What are some concerns I should have?
I'm a .net guy, so I would like to be able to create this in visual studio, if possible.
Here are some advantages and disadvantages that came to my mind:
Advantages
can be deployed on every server, as it's just static html
has partials, that can be reused, in contrast to normal html, where you have to code/copy paste every thing
you can still code in an IDE
a non developer can edit code (sometimes at least)
Disadvantages
the template language is limited and sometimes a bit awkward/needs to get used to
you have something new in your environment, which has additional costs (more than one developer needs to know how to build the site, ...)
If you know your current toolkit well and you do not have a problem hosting another ASP.net project on your server, I do not see the need for you to introduce another tool in your tool chain.
If you want to do something, where users can generate content - like github does on the github pages - this is something you might consider.
As for Jekyll, we tried it on one project and being devs, who like to code, we ran into it's limitations quite early. You can work around this, but if you know a programming language you will be faster. It was still fascinating, how far we were able to go with just using Jekyll
With ASP.NET pages exist throughout the life cycle of the page, and able to work with request and session context. See this article asp.net page life cycle
HTML pages are static and you can not access any variable that is on the server.
I recommend you follow the step by step this link to go to just understand how to develop ASP.NET http://www.asp.net/get-started
I hope that helped
Vicente
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.
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.
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.