Re: Best configuration for a web developer

Hi,

I don't agree with you where you say the server extensions method was "clunky", but it does seem 999 out of 1000 developers didn't understand it, don't know how to set it up properly, and probably never will.

The web is all about cross-platform (x)HTML and HTTP. The tool you use to generate what gets sent to the browser is not important here, it could be cross-platform PERL/PHP or ATL/COM on Windows, or if you like bloatware and complications there's always good-old .NET

Microsoft tend to assume that everyone is on Windows with Admin Rights running a shed-load of server emulation technology and that the production server is also Windows and accessible via SMB/NetBIOS and that you've never heard of DMZs and Firewalls.

Once you hit the Enterprise level, however, you'll tend to find you are not allowed Admin Rights (for very good reasons) and that the production server may be sitting in a DMZ or behind a firewall or on the other side of a router or maybe not running Windows at all. This is where the server extensions (originally written by Verneer Technologies) suddenly become very useful. e.g. I can open all the sites I maintain from my home computer in VS.NET and work with them almost the same as if I'm on the LAN. It's also great for server migrations - just press one button and you can "publish" to any server anywhere in the world - even UNIX. Another advantage is that all HREFs are relative and based on HTTP as opposed to "Clunky" Windows FileSystems where you end up with paths like

\\myServer\wwwRoot$\somesite\somefolder\somefile.aspx

Web developers don't need that kind of nonsense; it's a bit like creating a website and putting absolute HREFS for every link or absolute positioning for CSS. Another advantage of the extensions is that they were designed "from the ground up" to support multiple developers working on the same site at the same time.

Up to and including VS.NET 2003 the web developer model made a lot of sense and you could switch online/offline between remote and local IIS and all using HTTP. In Visual InterDev they had the "Local and Master" model.

The model is VS.NET 2005 appears confused. They've tried to hide the reality of web development and pretend you don't need server extensions and that you can you use XCOPY or FTP instead! But then when you get to page 100 of the badly written docs it turns out you do still need server extensions to use HTTP (and HTTP is the protocol of the web) so you've wasted time reading the first 99 pages telling you XCOPY suddenly works through firewalls, works from remote computers and supports multiple developers all doing XCOPY at the same time...sigh. Then there's version control to sort out.

The "new" model is that you basically create a "website" on a local FileSystem and you can browse and debug it on the built-in VS.NET webserver which will work without Admin Rights. You can also open a "website" from source control if you have multiple developers. When you are happy with your site, you can then use "web copy" to put it on a real server or you can "publish" the built assemblies. Both choices are more "Clunky" than they should be and using "web copy" over HTTP requires server extensions on the target server anyway (sound familiar?)

What's not yet clear from the model above is what kind of limitations you run into using the built-in webserver? My guess is that once you start needing calls into remote databases, COM+ services, ISAPI extensions or other advanced interaction with "IIS" it may not work as expected. It's also not clear how well the process identity will travel over to remote boxes.

The other option is to use local IIS, but then you lose some of the advantages of how VS.NET 2005 has been designed to work. In my view working with IIS local and remote is "Clunky" and a lot more difficult than it was in VS.NET 2003. It's also not clear how version control fits into this model.

Joel Barsotti wrote: 
Hi,

I'm trying to determine the best way to setup vs2005 and my network for web
development.

It seems the most integrated method for development would be to use the
local IIS. This would be alright in my single developer enviroment, but it
seems less than ideal for a multi developer enviroment.  But given that I
really want to have use the remoteOnly option for error messages I feel
almost locked into this option.

Which brings me to a second issue with using local IIS, only one website
supported under XP.  Should I upgrade my OS to server 2003?

I guess I'm just trying to figure it out.  I was using remote website under
vs2003 but using frontpage extensions always seemed clunky and it's much
worse under 2005 so I'm really trying to streamline the integration between
my development site and my development tools.

Thanks,
Joel






--
Gerry Hickman (London UK)
.