Developing ASP.NET w/out IIS or Admin Rights

[Guest]

We are a team of programmers (8) who currently develop, test & debug our
ASP.NET (C#) web applications using a local version of IIS 5.0 and SQL Server
2000 Desktop. We have ONE development server (Windows Server 2003 w/IIS 6.0
and SQL Server 2000). Guidance from above is dictating that local web and
data services shall not be run on individual developer's machines. We have
already had our local admin rights removed, which is making it very
difficult, to near impossible to step through and debug our applications
(I've tried to make the aspnet_wp.exe run under a different account but then
I couldn't get the web application to run)!

My question: How can a team of 8 developers test & debug applications
without having a local version of IIS on our developer's (local) machine
(Remote Desktop?, develop w.out debugging? etc.) It is very frustrating to
our developers and we hope to find a solution that lets us be productive and
abide by the rules bestowed upon us.

 

[Chris Fulstow]

You might be able to collect remote debug information from your
development server using DebugView from Sysinternals:
http://www.sysinternals.com/Utilities/DebugView.html

 

[GroupReader]

I'm impressed that you kept your cool while asking that question.
Nothing ticks me off more than when a person is paid to develop
applications but isn't allowed to use the proper tools to do so.

Answer #1: You need access to IIS. Eventually you will need to
install the app on the server. You'll need access to do the
installation. At a minimum, you should have access to your local IIS
so that you can tell the administrator how to set up IIS on the web
server. Same goes for the database - how can you tell your DB Admin
what to do on the production box, if you aren't allowed to try it out
locally (or in a TEST environment) first??

Answer #2: Visual Studio 2005 solves much of this problem with the
"personal web server". You can run an ASP.Net app without IIS and
Visual Studio will launch it's own "personal" web server. This is an
okay solution for the bulk of development, but you'll still need to
refer to Answer #1 when it comes time to system test and install your
app. As for the DB, it's irritating, but not really that big of a deal
if you are not allowed to have a local SQL Server running. You'll
still have all the client tools installed, right? (Query Analyzer,
Enterprise Manager, etc...) Use this as an excuse for upgrading to
ASP.Net 2.0 and Visual Studio 2005.

 

[Guest]

You should certainly be able to turn on the Remote Debugging service and
debug apps from other machines. Seems to me though, that you are in a
development environment run by a bunch of paranoid idiots, to put
restrictions like that. I once worked at a company that treated its people
like little kids and I can tell you that I got out of there just as fast as I
could.
Peter

 

[Chris Mullins]

I've personally run into this doing development wok for the State of
California, and the County of Sacramento. In both cases, admins were worried
about an increased attack surface on developer workstations.

You could try convincing them that you can bind IIS to 127.0.0.1, so that
there is no increased attack surface available. You could also verify that
firewalls are running on your machines with port 80 as an incoming port
being explicitly blocked.

Fortunatly, VS.NET 2005 uses the personal web server, so you'll be alright
for 80% of your ASP.Net 2.0 development.

There are workarounds to your problem using a shared IIS server and remote
debugging. I've never had this work right in a shared environment. Too many
people each stepping on each other...

 

[Guest]

1st, thanks for the reply. Working on a gov't contract has restrictions I
give you that --- it's very hard to convince the it security/network folks
about what software/services/ports you need to have running in order to
remain a productive developer ---- their philosophy --- "SECURITY OVER
CONVENIENCE".

On my team we are the architects, developers, DBMS admins, etc. so we can
install our applications on the remote server. We are also informed that ALL
web servers must have valid SSL certificates (443); which is being
interpreted as local versions of IIS for development purposes.

I'm not really concerned about the SQL set-up, as you've mentioned we can do
anything we need with the Enterprise Tools installed on our local machine to
access the server. I do not know the affects we will encounter by having our
web services shut down and IIS removed from our local machines.

Q: Is there a work around, while still stepping through code and debugging,
with 8 other people developing, maintaining, and testing other applications
off of the same IIS Server on the remote machine.

I know we will definately be "stepping" on each other when it comes to
stopping/restarting services or rebooting the server, but it looks like we
will not have a choice in this matter.

Thanks in advance.

We only have one version of VS.NET 2005; all developers currently have
VS.NET 2003.

 

[Guest]

You should certainly be able to turn on the Remote Debugging service and
debug apps from other machines. Seems to me though, that you are in a
development environment run by a bunch of paranoid idiots, to put
restrictions like that. I once worked at a company that treated its people
like little kids and I can tell you that I got out of there just as fast as I
could.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

 

[Juan T. Llibre]

re:

1) How do you make IIS 5.0 accepting C# script? It fails with the error msg:
"The scripting language 'C#' is not found on the server."

You need to install either the .Net Framework 1.1
or the .Net Framework 2.0 ( go for the 2.0 version... )

They both install support for C# (and VB.NET).

There's links to the downloads at :
http://msdn2.microsoft.com/en-us/netframework/aa731542.aspx

re:

2) The "local" development server which comes "for free" with VS2005. Can
you see it from a remote machine?. I could not achieve that.

No. It only works as a local test server.