As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've looked at several URL rewriters for ASP.Net and IIS and was wondering what everyone else uses, and why.
Here are the ones that I have used or looked at:
ThunderMain URLRewriter: used in a previous project, didn't quite have the flexibility/performance we were looking for
Ewal UrlMapper: used in a current project, but source seems to be abandoned
UrlRewritingNet.UrlRewrite: seems like a decent library but documentation's poor grammar leaves me feeling uneasy
UrlRewriter.NET: this is my current fav, has great flexibility, although the extra functions pumped into the replacement regexs changes the standard .Net regex syntax a bit
Managed Fusion URL Rewriter: I found this one in a previous question on stack overflow, but haven't tried it out yet, from the example syntax, it doesn't seem to be editable via web.config
There's System.Web.Routing that was just released with .NET 3.5.
You can just use Request.RewritePath() in a custom HttpModule
I prefer using an IHttpHandlerFactory implementation and have full control over all incoming URLs and where they're mapped to.
If I were starting a new web project now I'd be looking at using MVC from scratch. That uses re-written URLs as standard.
+1 UrlRewritingNET.URLRewrite -- used in several hundred services/portals/sites on a single box without issue for years! (#Jason -- that is the one you're talking about, right?)
and I've also used the URLRewriter.NET on a personal site, and found it, ah, interesting. #travis, you're right about the changed syntax, but once you get used to it, it's good.
IIS 7 has an URL Rewrite Module that is fairly capable and integrates well with IIS.
I've used UrlRewriting.NET before on a very high-traffic site - it worked great for us. I believe the developers are German, so the English documentation is probably not as good as it could be. I'd highly recommend it.
I've had a good experience with Ionic's ISAPI Rewrite Filter which is very similar to ISAPI_Rewrite, except free. Both are modeled after mod_rewrite and are ISAPI filters, so you can't manage them in code as you have to set them up in IIS.
I would not recommend UrlRewritingNet if you are in an IIS7 Windows 2008 environment.
Reason:
UrlRewritingNet requires that you app pool mode = Classic and NOT integrated.
This is not optimal
Also, their project seems very dead that last 2 years.
I just installed Helicon's ISAPI Rewrite 3. Works exactly like htaccess. I'm diggin it so far.
I used .NET URL Rewriter and Reverse Proxy with great success. It's almost on par with mod_rewrite and uses almost all of the same syntax's. The owner of the project is extremely helpful and friendly and the product works great. This gem provides both Rewriting and Proxy functionality, which many solutions don't offer. IMO, worth a look.
+1 for UrlRewritingNet.UrlRewrite too but why do I always need to end my URL with .aspx? I think it should be improved better regular expression partern.
Why do I always have to end with aspx in virtualURL localhost/Products/Beverages.aspx", "localhost/Products/Condiments.aspx". I just want to type localhost/Products/Beverages", "localhost/Products/Condiments" which look like MVC route.
This one look good but it is not working for my site. I still can't figure it out.
asp.net routing serves the requirement of url rewriting as well and even much more than. With asp.net routing you can not just "rewrite the url" but create custom handlers for various requests.
asp.net routing however requires at least asp.net sp1.
The basic thing that you do for a simple routing to work is add a few route handlers in the Application_Start even inside the Global.asax.cs file.
protected void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
private static void RegisterRoutes(RouteCollection routes)
{
routes.Add("Routing1", new Route("/Blog/id/2","/Blog.aspx"));
}
Related
Dumb question (maybe) I have searched online but I'm looking for somewhat a yes no type of answer. If you ever see a website with just xxx.com/xxx.aspx ... was that application created using Web Forms? Is ASPX only associated with Web Forms?
Thanks
To answer your question in yes or no (as asked), NO.
You can do that in ASP.NET MVC as well, by setting up the routing in that fashion. But I don't think anybody would do that.
On another note, if you have come across a website which is xxx.com/xxx.aspx, you can make a decently good bet that it was developed in ASP.NET WebForms.
Hope that helps!!!
Technically no. The web server software determines how to handle every request. It could be configured pretty easily to say that any requests for a file with a .aspx extension should be handled by the PHP parser, or Ruby, or whatever. Or, if using ASP.NET MVC, you could set up routes that resources that end in .aspx are still handled as MVC pages.
Of course, there aren't many reasons that someone would WANT to do that. The only reason I can think to do so would be if you're explicitly trying to make people think that a page is using a different technology than it is. And I don't see that being a common goal.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a website that primarily renders pages from a database. We also have a user management system in the website, requiring login, profile management, credit card processing, etc. There are some places in the site that have application functionality, like a forum, but most of the site is dynamic content, rendering from a the database. Content is entered with an inhouse CMS that is not tied to the website.
I'm upgrading the website from ASP to .Net 4.5 framework. What is the best option for this new project in VS 2012? An ASP.Net MVC 4 Application (Internet Application) or a new ASP.Net Web Site (Razor v2)?
I'm leaning towards ASP.Net MVC 4 Application (Internet Application, Razor), instead of Web site.
UPDATE: I've actually done a lot of reading on this, whether here in SO, or other sites, and still am not sure which is the best option for migrating to .Net from classic ASP for my specific needs.
Current:
Classic ASP website (100's of pages), public facing.
Most pages are rendered from a database, with template HTML in .asp page, when data populated from database. Could be compared to a WordPress site in function. Content is entered into CMS, and rendered on the website via templates.
Members log in to the site, have profiles, make payments, and more.
Have a forum
All URLs designed for search engines. URL Rewriting in IIS. I need to keep the existing URLs, and have them work with the new .Net site. IMPORTANT.
Client side operations are a must, integrating with jQuery tools, lightbox, etc.
This is not an "application" website, per say. It is a public facing website, like MSNBC or similar, that gets updated frequently (several times per month, if not more).
I'm at a loss for choosing the ideal project type for this migration to .Net. I don't think web forms are a good choice, and MVC 4 appears to be a good choice based on what I've read, but perhaps I can do everything that is necessary with a standard ASP.Net Website (Razor v2) template.
I'd like to get some opinions on which way to go with this, from people that have done it already. Thanks for your help.
I would use .NET MVC 4 . But there is not much online source if you get stuck. But I think you will survive anyway. The only downside is that you need more time to learn the new stuff because it is very different from the old stuff.
If you have enough time, go with the MVC 4. Once you do the project with it, you can do any changes easily in the future.
There are three kinds of websites you can create out of the box (and a number of subtypes). ASP.NET WebForms, ASP.NET Web Pages, and ASP.NET MVC. Which one you choose is as much a matter of personal preference as it is anything else, although certain kinds of sites make certain things easier to do.
In general (and these are not hard and fast rules)
WebForms - This is the way that 90% of the people do it, and there is lots of knowledge and books and information out there. It works, but has a lot of things you have to deal with in terms of creating standard conforming html, testability and maintainability. There are solutions to all these problems, and they're well known, but in general it's considered "old technology" (not as old as classic asp though)
WebPages - This technology is based on the Razor view engine, and treats pages more like classic ASP where you intermix code and html. In general, this allows you to quickly create web sites with functionality behind them, but at the cost of longer term maintainability and testability. As with anything, you could force process to solve these problems, but the framework itself is not really geared towards it.
MVC - This technology is based on the well known and well understood MVC user interface pattern. It focuses on separation of concerns to improve maintainability, testability, and ease of development. It does require a significant departure from traditional ASP.NET development, and a steep learning curve. You have to know HTML, CSS and JavaScript in much more depth than with WebForms.
I use MVC for everything I can, it's just more logical for me. MVC is one of those things that is really confusing until you reach an "ah hah!" moment, then it all snaps into place.
What you choose is entirely up to you. You have to decide HOW you want to develop, and that will guide your decision.
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).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
There are a lot of webs still using classic ASP instead of ASP.NET but that is not the question - "never change a running project".
The question is if it is still a first choice as a base for a new web-project or would it be worth to switch to ASP.NET? Would you recommend a classic ASP programmer another language to switch over? There was no single update to classic ASP since it first release but a lot of companies are still using it for new projects. Deservedly?
While I would personally never willingly choose to create another ASP project over an ASP.NET project, the single biggest reason to do so is "skillset". I'd definitely recommend an ASP developer pickup ASP.NET, but if there is a project needed "now", go with what you know. Then learn ASP.NET before you have another project. :)
ASP.NET has a number of improvements over ASP, but we (the collective former classic ASP developer community) created a number of good applications using classic ASP.
In my mind, there is absolutely no reason to use classic ASP compared to ASP.NET Webforms or ASP.NET MVC.
Unless you need to integrate with existing classic ASP applications, since some things (notably session) are not compatible across app boundries, leading to creative workarounds (WebServices running on your localhost...yuck).
Coming from a classic ASP background I had the same questions. 3-4 years ago I took the route of moving towards ASP.NET/VB. I can tell you that the cross-over from ASP/VBScript to ASP.NET/VB is little to none. I was actually quite frustrated with the whole .NET platform for the first few months (more like the first year!) and kept rolling back to classic ASP.
In the long run, I ended up starting from scratch and picked up ASP.NET/C#. Oddly enough, I felt that the syntax of C# was more natural, even though my background was in VBScript!
For regular web development, ASP.NET is like using a sledgehammer when a simple ping hammer will do. However, the sheer power behind the .NET platform makes it invaluable in an enterprise environment where your web is often time blurred with your other applications.
Given what I know now, I would have likely made the move to PHP. Not only is the programming style similar, but PHP really is dedicated toward the web. Whereas it is quite easy to get lost in the mass of information the .NET platform provides. And the rate at which the new .NET techonologies have been coming out in the recent past can and has become overwhelming.
To directly answer your question: if you are staying in the realm of web development then I'd recommend taking a hard look at PHP for your new projects.
I'd be very hard pressed to recommend using "classic" ASP for a new project, but, as with any new project - it should always be about choosing the tool that's best for the job, rather than using "Tool X", just because it's:
newer
better
the "latest thing"
If, for example, "Company X" (who are a small company with 20 employees) needed a new web application for their intranet for logging holiday/leave requests and the intranet server was an ageing NT4 box, Classic ASP would be the way to go. I would make the recommendation that they upgrade to a newer machine that could handle a supported server O/S such as Win2k3, but it may well be the case that they simply don't have the budget/need.
For existing projects it's no option to switch to another language in my opinion until you have to make some radical changes / additions. Reprogramming is time-consuming and your customer will not pay for it normally.
PHP is a nice web-language in my eyes, no question. But I wouldn't use it for very large projects because it is not pre-compiled which makes a good speed-up (my experience). But I left PHP-Development a few years ago, maybe there are some good improvements to this now. Also I wouldn't run PHP on an IIS nor would I run Apache on a Windows-Server. So when your whole server-equipment is based on windows you would have to setup a new server with linux/apache/php - more costs for your company the customers will not pay for.
I agree with most answers, there is no good reason to stay with classic asp for new projects forever and there should be made plans to make a changeover to another language. We program most new projects still with classic ASP at the moment because we have a lot of selfmade libraries to use with our CMS etc. and we have to rewrite them with .NET/C#. Also there have to be established some new coding-conventions (e.g. how to make a navigation, folder structure, ...) so we are working alongside on a sample-project in .NET and after finishing with it we will only make small changes to existing projects until we have a chance to redeem the rewrite at least partially with another assignment of the customer.
It's a slow process but I believe it have to be done sooner or later. (And I'm a big fan of the .NET-Framework, too! :-) )
You might consider looking at some of the differences between ASP classic and ASP.NET. Having had to maintain both in the past, I can tell you that there are numerous pleasures to present in developing in .NET vs. ASP Classic. Transitioning to any web-trendy language (PHP, ASP.NET, Ruby, Python) is going to be worth it if for nothing more than to realize where ASP Classic lacks.
I think its high time to switch over to Asp.net. The better object oriented way of asp.net will definitely help you to reduce code management night mares.
For any remaining ASP holdouts, I'd actually recommend jumping ship to PHP. It's a lot more like ASP than ASP.NET, and there's no shortage of new work in it.
That being said, I greatly prefer ASP.NET (both MVC and WebForms) myself - but, I left ASP development about 7 years ago. ;)
Like another poster mentioned, the skill set of the staff would be the deciding factor.
If it's a Classic ASP shop and something has to be done ASAP (what doesn't, right?), then it might be hard to convince management that there's a need for .NET, especially if it impacts the timeline. This is where adding in some .NET pages for one-off projects comes in handy, since it lets the dev team become familiar with the language and decide when to switch from Classic ASP to .NET.
Going forward, it's important to remember that while Classic ASP still runs and runs well, it's not going anywhere and you can't count on any updates/changes to the language/tools going forward.
That being said, from my experience, I've found that jQuery/Ajax/DOM scripting gives the Classic ASP pages a new shot of life and add some of the "fancy/cool" stuff that my clients want to see on their sites.
I wouldn't write a new app/website in classic asp. Why? number of reasons:
1) no classic asp bugs are fixed any longer by MS, eventually the support will cease to exist, it has to.
2) .net is much faster performance wise
3) .net has a lot of useful extenstion (AJAX for example)
4) skillset - when thinking of a technology you have to be sure that you can find someone to maintain it easily in the future
.net has been around for awhile and it's tested, so it's safe (and recommended) to switch over, for new projects for sure.
well I honestly wouldnt... With asp .net you can take advantage of the .net framework, and object oriented programming... That alone is good enough reason for me to use asp .net instead of classic asp...
Our team has twice been asked to significantly "upgrade" a classic ASP site and in both cases, it was such a nightmare that we converted/re-wrote it in ASP.Net. I know the "Don't rewrite what's working" mantra, but knowing that we or someone else would have to continue to maintain the codebase and seeing how horrible the ASP code was to maintain, we decided to make a clean break.
For that reason alone, I see nothing to recommend ever writing anything else in classic ASP. If ASP.Net is not an option, I'd go with PHP or Ruby.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let's collect some tips for evaluating the appropriate use of global.asax.
It's simple to use if your session and application initialization code is very small and application-specific. Using an HttpModule is more useful if you want to reuse code, such as setting up rules for URL rewriting, redirects or auth. An HttpModule can cover everything a Global.asax file can. They can also be removed and added easily using your .config.
I've used it before to catch errors at the application level, and to do something when a user's session expires.
I also tend to use it a lot to provide static properties that read values from the web.config.
I think it ok for stuff like that, though I wouldn't put much more than that in there.
Initializing ASP.NET MVC. :)
Custom user authentication.
Dependency injection, like extending the Ninject HttpApplication.
Its a stiff drink, just be careful not to drink too much and you'll be ok.
I use it for global error handling, and setting up routes in mvc. You don't want to be writing global page_init code in there though.
If you stick to application level events, and make most of the logic actually live in classes that just get called during those events, you will have no problem making use of the global constructs.
It's a nice spot to grab session initiation, and even request initiation. Others have mentioned the error handing aspect, although be careful of exceptions thrown from non-asp.net threads (eg. threadpool or custom thread) as they'll bypass the global.asax handler. Personally I always have one, I think of it as simply part of the plumbing.
I used to use Global.asax for things such as error handling etc, however, I have since gone to using HttpModules to replace this as I can copy it from one project to another without editing the global.asax.
Con of using Global.asax compared to an HttpModule : You will be tempted to write code that's hard to reuse because it will be too tied to that particular application.
I haven't really used Global.asax. I used it's equivalent in classic ASP all the time, but that had mostly to do with certain configurations like database connection strings and such. The config in .net makes a lot of these things a lot easier.
But if you want to implement application and session level events, this is where ou need to go.
Global.asax can inherit from your own class that inherits httpapplication. Gives you more options as well as putting the bulk of the code you might have in global into a class library.
EDIT: Having your HttpApplication class (global.asax parent) in a seperate class library can promote reusability too. Although i agree that using HttpModules is better suited for many tasks, but this still has many uses, for one, cleaner code.
The Session_Start event in Global.asax is a wicked good place to initialize your session variables.