I am working on a mobile site that uses .aspx for the pages; however, I am transferring information from older .asp pages. These .asp pages are reading database connections, and I am not clear how to convert these into .aspx pages without running into config errors that are unclear to me in fixing.
Is it bad practice to mix .asp and .aspx pages in a site? If not, how can I learn to better understand the conversion differences from .asp database connections to .aspx? This is the only obstacle I have going on at the moment with this site, and I would love to find a solution soon as I've been stuck here for a while.
The site works, but I would like to be consistent with the .aspx set up in pages. I appreciate any help you may have to offer, thank you.
You can absolutely mix ASP pages with ASP.NET pages. I've done it for internal sites where we didn't have time to redesign, but needed to add some functionality. Note that you can't share session state between the two types of pages (I worked around this using cookies) but the two pages can live together in the same web site without an issue.
Often ASP pages will have database connections kept in the global.asa file or perhaps in an include file, or even right within the asp pages themselves. It would be helpful as you migrate functionality to have all those connections in one logical place.
There is no straight conversion to ASP.NET from ASP, and if you don't have much experience yet with ASP.NET it would be worthwhile to explore some samples / tutorials to get an understanding of how an ASP.NET Web site works. There are lots of options for how you connect to your database. Have a look at www.asp.net to learn about them.
You can have the two running together. It's not necessarily a bad practice to mix the two, but here can be some technical things that you'll have to work out. Since it sounds like you're trying to convert a classic ASP site to ASP.NET, if there are not too many pages, I'd probably try to figure out the conversion issues so that all of your pages are running on ASP.NET.
Otherwise if you do want to run ASP and ASP.NET side by side, if your website has session state or authentication and you need that shared by both asp and asp.net pages, then you need to ensure that you have a strategy to handle that kind of stuff. This thread details session management issues to consider when running ASP with ASP.NET, for example: Classic ASP and ASP.NET Integration.
Related
I'm just starting to convert an existing ASP.NET Web Forms website to ASP.NET MVC. However, MVC seems excessive for some pages. ASP.NET Web Pages seems like a better fit for simple pages where the benefit of MVC is unclear.
If I use ASP.NET Web Pages for some pages and MVC for the rest, what difficulties will I likely encounter that would not occur if MVC was used for every page?
Here is one difficulty I am already aware of: Web Pages and MVC cannot share _Layout.cshtml.
EDIT
The content above was heavily edited to clarify the intent of the question.
I did a little research into this and now fully understand the scope of your question. Sorry, it was my mistake for thinking you mean Web Forms and not the relatively new Web Pages.
Any answer anyone gives here will be pretty subjective, but my take on this is to go ahead and stick to the MVC method instead of mixed modes. It appears that Web Pages is a razor based HTML file without a controller/action associated with it. If that is truly the only major difference / reason for your question, then it seems the extra three lines of code it would take to make it MVC...
public ActionResult StaticFile(){
return View();
}
actually will make it a) easier to add dynamic data to in the future, b) more directly ties into routing (no special routes for static for example) and c) easier to interact with the server-side if you have to do any kind of authentication, session tracking, etc, etc. Anyways, my 2 cents. Go the way that works, but keep in mind the trouble/frustration of future modifications as you go forth with your site. I post this opinion with the admission of never having used Web Pages, just a few hours of reading about them.
The biggest pain is the maintenance of a Master Page and a __Layout view. That being said I am with Tommy - why not just make these static pages html files and not aspx pages.
I decided to abandon ASP.NET Web Pages and use MVC exclusively on my website. The primary reason was because of the duplication of effort for things that could not be shared between Web Pages and MVC. Here are some things I learned.
Web Pages and MVC could not share _Layout pages. I was able to work around this by moving shared content into sub-layout files that the Web Page _Layout and MVC _Layout files could share.
Forms authentication was no problem.
I was not able to figure out how to implement MvcSiteMapProvider in the Web Pages for breadcrumb functionality. (See this question.)
The MvcSiteMapProvider difficulty made me realize that it was just a matter of time until I found something else that could not be easily shared. Therefore it seems smarter to stay with MVC rather than taking a hybrid approach.
I've got a lot of Classic ASP pages in production on a Windows Server 2003 64-bit machine. I've also got .NET on there working.
I'm starting to move the ASP ajax pages (pages that receive ajax calls from the Classic ASP) to ASP.NET/C# to take advantage of the business/data/logging layer I've got set up there in C#.
I've figured on securing the ASPX pages by way of a "token" that I create in the database in ASP and then pass to the ASPX page, which then uses it to validate that it's a legit call and destroys it.
My big question is - aside from making the ASPX pages, do I need to compile the app into the same site as the ASP site? I assumed I'd do that - deploy it there alongside the ASP Classic pages, and then just call the ASPX individually as needed.
Is this strategy sound? Do I need to do anything special for performance or configuration to make ASP Classic and ASP.NET coexist well?
Thanks - this migration has been a bear because of the extreme asp classic dependency.
It will work just fine. I've seen it on several sites. Just put them all in the same directory.
Your biggest issue will be that the ASP and ASP.NET pages will each have their own SESSION and APPLICATION variables which won't be shared between the two. If you are using session variables in either it can force you into doing a lot of hacks to make it all work together well.
For reasons not in scope of this question I have implemented a .net project in an iframe which runs from a classic asp page. The classic asp site persisted a few sensitive values by hitting the db on each page.
I have passed there variables as xml to the aspx page, now I need to make these values available on any page of this .net site.
I've looked into the cache object but we are on a web farm so I am not sure it would work.
Is there a way I can can instantiate an object in a base page class and have other pages inherit from the base page to access these values?
What is the best way to persist these values?
A few more points to consider the site runs in https mode and I cannot use session variables, and I would like to avoid cookies if possible..
Perhaps I've misunderstood but, if the ASP classic pages were just hitting the db why didn't you just have the ASP.Net pages do the same? That would certainly solve the web-farm issue and is probably why the ASP classic pages work that way to begin with.
The only thing I was able to find on the subject was a posting from 1997
(http://insecure.org/sploits/microsoft.asp.iis.html), so I was hoping someone on here might have more recent knowledge on this topic:
Does anyone know if there are any known vulnerabilities in IIS6 that would allow a user to view an unprocessed ASP or ASPX page, outside of gaining control of the server?
IIS will serve raw asp or aspx only if those extensions are removed from application mappings for the site, or if you done some other dumb thing to configure it that way.
Why would you want unprocessed asp pages? You could just have a link that will escape the page and put it into a webpage for the user.
To me it would be a potential security risk, as, if you forgot and left a security vulnerability it would be seen.
If you didn't have your script mappings set up properly, this could be an issue, but that's more of a deploy-time concern, not a run-time concern.
I think any other vulnerabilities in this area would be app-related (picking a file to download server side...), not so much platform related.
Are you concerned about people being able to see your source code? If it is, I wouldn't worry too much about it, especially with .net and using code behind files, and a properly architectured n-tiered site.
Really, the only time this is a concern is if you have an error on your page and you spit out debugging code, even with classic asp.
I have a large-ish web project which is migrating from classic ASP to ASP.NET (about time), and would like to redirect requests from the old addresses, such as:
/some/path/old-page.asp?foo=bar
to the new addresses:
/other/path/new-page.aspx?qaz=bak
For a fairly long time, there will be classic ASP pages running in parallel with ASP.NET pages, with individual pages being replaced by their ASP.NET versions over time. Where possible, I want to redirect from the old pages to the new ones to keep users from receiving 404 errors, and also to keep the accumulated PageRank on the pages.
My question is, how would you do the redirection logic from the classic ASP to the new templates? The obvious solution is to replace old-page.asp with some simple VBScript that redirects to new-page.aspx, but in the long run I want to get rid of the old .asp files, so I would like to implement the redirection in such a way that they will exist also after the site is completely running in .NET.
One option would be to map the .asp extension to ASP.NET, and implement the redirection as an HttpHandler, but I guess there is no way of making the classic ASP engine run after the request has been passed to ASP.NET.
A couple of years ago, I ran into the very same issue at an eCommerce company where we upgraded their website to .NET. The main issue is that we had no idea how many customers had the old asp pages in their favorites, as well as the issue of SEO. Yes you can map the asp extension to ASP.net, but you lose the ability to run the asp files at all, so that would require that you update ALL asp pages, which may not be feasible.
The best solution I found at the time was to implement an ISAPI redirection filter in IIS. This is an app that is run by IIS BEFORE, the asp or asp.net runtimes. It would make a decision based on the url or any rules you want, whether it should allow the asp files to run or whether they should be redirected, or use url-rewriting to handle the request. It is not always a clean operation, since it runs before your website's request do, and confusion can happen later if other developers don't know it is running. So make sure if you go this route, that your website has plenty of comments or documentation to let developers know there is this thing in IIS running...
There is a good explanation of how to implement this in Code Project. Go here and check it out. http://www.codeproject.com/KB/ISAPI/isapiredirector.aspx
Good Luck!
You should use the "HTTP 301 - Permanently Moved" response code, as this is precisely what it is designed for.
http://en.wikipedia.org/wiki/HTTP_301
An ISAPI redirection filter will work in the sense that, yes, it will redirect visitors to the new URL.
However there are three key problems with the ISAPI redirection strategy.
More code to write/maintain
Bookmarks and search engine entries will never be updated with the new and correct URLs
If foo.asp is transparently redirected to bar.aspx and both are indexed by Google, you'll have two duplicate URLs to the same content in Google. This clogs up search results and is actually against their TOS I believe.