Re: Best configuration for a web developer

Well at least there wasn't something obvious I was missing :)

So with one developer, one development site, and one deployed website
(remote and behind a firewall, but with both HTTP and FTP open), what would
you recommend?


"Gerry Hickman" <gerry666uk@xxxxxxxxxxx> wrote in message
news:%23h1gLrWFGHA.3172@xxxxxxxxxxxxxxxxxxxxxxx
> 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)


.

Loading