I’ve never tried this, but the things to check are:
- What’s in your path under IIS and what version of Ruby
does it point to?
Not entirely sure what you mean, but I’ll try to answer. The home
directory for the web site in question points to my rails app’s public
directory. The ISAPI extension mapping associates .rb with
c:\ruby\bin\rubyw.exe, which happens to be ruby-1.8.4.
- Does your shebag #! line in dispatch.cgi point to
someplace other than c:\ruby\bin\rubyw.exe?
I’m using dispatch.rb, not dispatch.cgi, not that it really matters as
their contents are identical. The shebang points to c:\ruby\bin\ruby,
not that it matters as the shebang isn’t interpreted in windows. In any
case, changing it to rubyw had no effect.
Let everyone know in case we need to deploy under IIS.
Easier said than done, it would seem. None of the IIS+FastCGI recipes
I’ve tried work, and debugging data are scarce to non-existent even when
you get close. I’m also evaluating using mongrel with IIS proxying in
front of it, which does work quite nicely, but relying on a single
mongrel process seems to present scalability issues as the number of
concurrent requests rise, and not only does mongrel_cluster not work in
win32, it requires another component to do load balancing of requests
across the cluster. That component seems to typically be pen, another
piece of software unavailable on win32.
Guessing that perhaps if I can get CGI working properly, FastCGI might
follow, I’m trying what should be the simplest (and slowest) method, and
as you can see, have been stymied.
- donald