Configuring CGI support in IIS
 

Server-side development doesn't begin and end with ASP. CGI languages are a valid alternative. this article shows how to configure two common CGI languages on your IIS box.www.tartoos.com

In used to be a distinct non-fan of Perl/CGI. it wasn't my friend back then, before I left the UK for sunnier shores. It looked obtuse to me, and all the talk of Perl being a 'write-only' language probably rubbed off. These days, I'm actually a bit of a fan of not just Perl, but other languages too - including TCL. In this article, I'll be showing you how to configure your IIS webserver to allow you to use these languages in CGI scripts. These languages are fun to write if your mindset can extract 'fun' this way - and CGI is one of the best ways for a web developer to learn them.www.tartoos.com

First, lets talk about the languages themselves. They're both well-established languages, Perl in particular being ubiquitous, and both are open source with a throng of adherents from all corners of the development community. Better still, they're both free, and hey, who doesn't like free stuff? Both are available in windows form from several sources, though the one I recommend is ActiveState Tool Corporation. Heading off to the ActiveState website, you'll be offered with windows downloads of each language package, which includes the language interpreter, documentation and a whole bunch of samples to get you started. Now, if I have to explain how to install these you probably shouldn't be going any further - download them and get them installed - it's a simple process. Once you have these beasties installed you can read on.www.tartoos.com

Now, if you installed ActivePerl after IIS, the installer will have done the majority of the configuration for you. I'll explain the IIS end of things anyway, since the process will need to be repeated for the TCL interpreter.www.tartoos.com

Fire up Internet Service Manager. You should be presented with your website list, as seen below

Find the website you want to install CGI support into, and right click the node to bring up the 'properties' dialog.

Go to the 'home directory' tab and hit the configuration button you see there

You'll be presented with the following dialog - as you can see. Perl is already configured on this machine, so that should give you a hint of how it's done.

SO, hit the 'add' button and het ready to fill in the values you need

For Perl, you should be using <path_to_perl>\bin\perl.exe "%s" %s, with a file extension of .pl (though you can actually use any extension you like), and allow GET, POST, and possibly HEAD verbs, and make sure 'script engine is checked.

For TCL, use extension .tcl , and <path_to_tcl>\bin\tclsh.exe %s %s and allow the same verbs, not forgetting the script engine box. Be aware though that different versions of TCL may have different names to the tclsh executable - mine is tclsh83.exe

Don't drop the little %ses, or the executable will never recieve the name of the script it's meant to run and therefore nothing will happen.

All you need to do now is add execute permissions to your CGI-BIN directory, and write two little 'hello world' scripts to test your engine. Dead easy Perl first, then TCL

print "Content-Type: text/html\n\n";

print "<b>Hello world<b>";

now TCL

puts "content-type: text/html\n\n";

puts "<b>Hello world<b>";

Multisite Development Methodologies using IIS

IIS development methodologies, for your delectation

I've been using IIS for pretty much all my professional career. It's a darn good web server. I started out using IIS4.0 and IIS3.0 back in the glory days of the web boom at an agency in London. Now I'm working in Australia, still using IIS, but now I'm running my own servers and I'm part of the IIS MVP team. It's about time I shared with you a couple of the development methodologies I've used as they pertain to developing multiple websites using IIS. I won't be talking about code here, I'll be talking about how you can set up your IIS machines for smooth development of new websites.

Method one : the subfolder method

This method is usable by users of any IIS flavour, from PWS right through to .NET server. It's the method we used when I was at Pres.co in London, and while it takes a little discipline to run smoothly, it's a simple way of building a lot of sites on a single server, especially if those sites aren't very heavy on server-side development.www.tartoos.com

It involves, basically, developing each website in its own subfolder, for example http://server/website1/ and http://server/website2/

For this method, the developer initialising a new site doesn't need access to the IIS machine itself, just filesystem access through a network drive. Workstations within the office are configured with a network drive to wwwroot on the development server, and to start a new site, the developer just needs to add a new folder. You can then code away to your heart's content. Though the discipline starts right away.

The discipline is in being aware that the path will change from development to deployment. Relative paths are fine, but mostly we used absolute paths from the root, e.g. /server1/images/image1.gif.www.tartoos.com

When it comes to deployment time, the developer has to follow a specific method. For initial deployments, the developer copies the entire site to a temporary folder, then uses a search and replace tool to search out all the absolute paths "/server1/" and replace them with "/" within that temporary folder. Then the developer can simply upload the site with FTP and everyone is happy. For updates an interrim development, a slightly different method is used. Using Windows' search function, the developer seeks out all files updated in, say, the last day or so. He/She then selects all the files returned by search, and adds then to a zipfile which preserves the folder structure. This file is then unzipped to the temporary folder, replaced out and uploaded. It's incredibly important to use this temporary folder step, otherwise it can be a hell of a job to restore all the paths correctly, as I found out one late night to my own detriment. I lost half a day's work restoring a site to a usable state, and was still picking out the occassional broken path a week later.www.tartoos.com

The drawbacks in this method are, as you can already tell, the risk of screwing up your pristine development site, and a lack of isolation from other sites. If IIS is not set up apropriately with isolated applications, Session variables and Application variables become nigh on unusable. You can get into a tangle with server-side paths, having to use MapPath() where you could simply hardcode a value. You could even fall foul of replacing out the wrong content, since in one of my apps I've used regular expression to replace path elements - the search replace functions can't distinguis between the path /site1/ and the regular expression /site1/gi. There are ways round this, but again it requires discipline at development time. Nowadays I use method 2.

Method 2 : multiple isolated sites

Each site is configured separately. This is essential for serious ASP development. The way I work is to add new websites as I need them, running each on a different IP port, for instance, site1 may be configured on http://server:5153/ and site 2 on http://server:5154/ - it keeps things 'neat', in a way. It requires a little bit of setting up. The way I set up my fresh server is like thiswww.tartoos.com

First, I move all content from wwwroot into a subfolder, say 'home' or 'homepage'. Then I alter the home directory path for my default website in IIS to point at this folder. When I add a new site, I create a folder under wwwroot with a nice descriptive name, often the domain name, then under this I create a /private/ folder, an /htdocs/ folder and a /logfiles/ folder. This mirrors the set up on my hosting account. I then add a new website to IIS Service Manager with a new port number to point to the /htdocs/ folder. This is where my website now 'lives'. I try to keep my port numbers sequential, but it's tricky to remember which site is on which port after you add five or more, so I use the homepage of my default website to provide me a set of links to each site. I then add a mapped drive to my workstation pointing to wwwroot, and I can access all my sites through a single drive. It requires less discipline to deploy an application this way, though its worth bearing in mind you can fall foul of your own quirky coding if you're not careful. The real value is that the path on the development server exactly mirrors that on the live server. I've been using this method for about two years now, and it's worked brilliantly for me.www.tartoos.com

Youo can make this trick even easier if you have an internal DNS server at your office, even if it's on your own machine. Simply set up a new DNS entry with the name of your site to point to your IIS box, and use Host Headers to process the incoming request - giving you an easy to remember name for each site rather than needing to remember port numbers. Obviously you need a full version of IIS to use methodology 2 - A professional edition operating system is not usable this way, but if you're a pro developer you likely have a server OS available to you, and if you're a small developer, perhaps running your own business or developing a lot of different sites, you'll find the investment of great value. I run Windows 2000 Server on my home desktop machine, with an NT4 Enterprise Server sitting next to it. My laptop runs Windows 2000 Advanced Server, and I run a simlar setup at work - for a developer it really is essential to run the 'real deal'.www.tartoos.com