MC, > Why is it a must to keep the asp.net pages in a so-called 'application'? I > don't really understand what's meant by an application exactly...coz I am > used to writing php/perl CGIs, and seems that they don't have such concept.
Here's a few short reasons that the application paradigm makes sense for Mono web applications: No offense, but PHP and Perl scripts are single file answers to small problems. Yes, they've been used for enterprise web sites, but that was beyond their original design idea. Having an application paradigm immediately brings continuity to dozens of files and allows them to communicate with each other, and NOT with other pages that are on a different site. Now, enough marketing. Down to earth, the reason for applications is that Mono and .NET pages are not scripts running on the server. They are compiled code (not to CPU native code, but compiled nonetheless), and their assemblies have to go somewhere. A web app generally produces just one assembly, with the code from all the pages. This allows for web pages across a web app to be served very quickly. If all aspx files were single and didn't belong to a web app, no assembly could be easily referenced by the server, and ASP.NET would be slow. > This idea annoys me because my apache is configured to serve mass virtual > hosts dynamically. Usually for the perl/php case, I just need to map *.pl > *.php to their respective handler. But for the asp.net (or maybe even the > JSP as well?) There is definitely room for single ASPX files in cases like this. I wish this were an option. Just some thoughts to help you cope with how it works. Andrew Arnott
smime.p7s
Description: S/MIME cryptographic signature
