On my development machine, I'm using a virtual under the Default Web Site. On the production server, I want to run a full-fledged site. Should I just be developing that way. Because the INI has the virtual in it. And the Config program (that runs when you run the server EXE using the Config parameter) uses that INI when it does the server config. So will I end up with a virtual under the Default Web Site and not the full-fledged site like I want? This was always a bit confusing to me, but is more so in WC7. I believe I used to do a web site creation in IIS, then use Console.EXE to configure it, since the Console program did not seem to be able to create that full-fledged site. Now it's done programmatically and I'm unsure what I'm going to get when I configure the server (which I'm trying to do at the moment).

I would recommend trying to match your local and server environment. Although you can run a virtual local and root on server, the problem is that if you get your links wrong you can have a problem and may not notice until you publish. Specifically any URL that starts with / will behave differently in the two environments. You can work around that with using relative URLs and always making sure to use ~/ or explicitly resolving paths, but it's just easier to not have to worry about it and be able to see what you'd expect to see on a live server in your dev environment.

However, running in root on IIS is a pain on a local machine unless you only have a single site and you're willing to dedicate that to your app. On a server it's easy as you can easily use DNS to map multiple sites but on a local machine you're unlikely to have multiple domains set up so you need to juggle ports which sucks.

Better to use the Web Connection Web Server or IIS Express which are local servers that you can point at a server. And if you have a new project it's easy to switch between the different Web servers with the Launch.prg by changing the default that is used. As a bonus with either of these solutions you can use https:// urls locally.

I very rarely run IIS locally any more (only for load testing or very specific test scenarios) and always use the Web Connection Web Server which i can start as needed and shut down when done.

+++ Rick ---

Yeah, I'm starting to think matching the two environments is best. However, one thing you were saying confused me. You said "running in root on IIS is a pain unless you only have a single site and you're willing to dedicate that to your app." Did you mean locally in development? Because I'm not sure why it would be a problem in production. I have multiple websites, each on a different IP.

Yes I meant locally on the dev machine. On a live server it's easy to map multiple domains via DNS, but you can't do that quite so easily on a local machine. I suppose you could with a hosts file and custom domain mapping but not very portable. Much easier to just use one of the local Web Servers that can just run on a local root port automatically.

+++ Rick ---

I'll have to delve into using the other options. I am used to using IIS with a virtual locally and a root level site on the production server. But that may be a bad habit. I guess I like dev and testing with what will be used in production. Will differences crop up when I go live or do these other options work exactly as IIS will? It's just something I'm presently unfamiliar with.

Well, it works either way, it's just easy to create invalid link paths and not notice it until you get to production. As long as you're diligent in how you create your links with relative paths or ~/ and not rely on / you'll be fine.

It's much easier though, to just assume you're always running out of a root because then you can just use / for root referencing everywhere which is more efficient as Web Connection doesn't have to recalculate and replace paths in the output.

+++ Rick ---