The January publication of MSDN Magazine carried an article titled "Enhance your apps with Integrated ASP.Net Pipleline". While the subject of the article is not something that I would normally be super excited about, I decidede to spend at least 10 minutes perusing the article while commuting to work this morning (Been riding the train past couple of weeks). I recently installed Vista on my Notebook, and was keen to start looking into the features of IIS 7.0, which ships with microsoft's latest desktop operating system. As it turned out, the article touched on a subject that might be useful down the road as we take a leap into the world of PHP programming at work.
Its long been common knowledge that PHP could run under IIS, but not in a way that would make it feasible to run production apps...in other words, if you configure your PHP apps in IIS 6.0/5.0, the result would be a web site that runs very slow, if nothing else, due mainly to the lack of thread safety in PHP apps. Alternately, the app could be configured to run under IIS using CGI, but CGI is a resource hog (one process per request) and results in an app that scale poorly in IIS.
The latest version of IIS(7.0) now allows for the targeting of none .Net Framework apps. Through its "FasstCGI" component, core ASP.Net features can now be used declaratively in Apps written to target other Frameworks.
For example, IIS 7 allows PHP, Ruby, Perl etc to utilize the ASP.Net Integrated mode engine to take advantage of features like ASP.Net membership and forms authentication, login controls etc. The new ASP.Net Integrated Pipeline feature of IIS 7.0 also allows us the ability to leverage our .net skills in applying cool features such as URL-rewriting, Output caching to these none asp.net apps by writing modules that can be plugged directly into the request processing pipeline via IIS. If you are unfortunate enough to be still running a couple of classic ASP pages within your .net Framework application, you will be releieved to know that IIS7.0 now makes it possible for these classic ASP pages to utilize functionality that per previously unavailable under IIS 5.x/ 6.
If you are developing under Windows Vista, you already have acccess to IIS 7.0. On the Server end, IIS 7.0 will be realeased with windows Server 2008 in Late February. The FastCGI component will be avaialable with this release of windows Server 2008, under Vista, its available via Service pack 1.
ASP.NET Web.Config files provide a configuration system we can use to keep our applications flexible at runtime. In this article we will examine a simple technique for using the configuration system for the best results.
The < appSettings > element of a web.config file is a place to store connection strings, server names, file paths, and other miscellaneous settings needed by an application to perform work. The items inside appSettings are items that need to be configurable depending upon the environment, for instance, any database connection strings that will change as our applications are moved from a testing/staging server into a production environment.
Developers often find themselves having to take extra care not to overwrite web.config file as they move code from one environment to the next, typically from develeopment, to staging/testing, and finally to production. Let's take a look at a little known feature of the appSettings element that can give us even more flexibility (see source code in url below).
The appSettings element may contain a file attribute that points to an external file.If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.
This feature is useful when you keep user-specific or environment-specific settings in the external file. Let web.config contain those settings that are global to all the installed instances of your application, while each user or installed site contains their own settings in an external file. This approach makes it easier to move around global web.config changes and keep web.config checked into source control, while each developer can get their own settings separate.
One caveat to this approach is that the ASP.NET runtime does not detect when the external file changes. You’ll need to make changes to web.config itself for ASP.NET to launch a new version of the application with all changes in effect.
In the attached code snippet (see link below), lines 2 through 8 shows a typical implemention of a web.config file that points to an external configuration file. Lines 13 through 15 shows what the external file might look like.
http://www.solid2.com/jaycent/articles/code_display.aspx?codeid=adedb5b5-ca86-4dbe-9c5e-1a16dd45b292