ASP.NET/VSS in a multi-developer environment


Craig Hunt

I've searched high and low for an answer to these questions and have had
little success finding an answer, but I just know someone else has
experienced the same issues we face today.

The background:
We have seven developers who work on dozens of web sites operating on
various platforms. Most of our sites are classic ASP sites, but I have been
pushing for two years now to convert our largest sites to ASP.NET (VS 2003),
and on one of our largest sites, I recently succeeded in that effort. Using
classic asp and VSS presented us with no problems, but now that we've made
the move to VS2003, very little goes smoothly. I'm beginning to get a lot
of heat from my team as well as from my superiors due to the fact that the
team environment as it stands now does not work. When we developed the
site, we were using VSS and FrontPage Server extensions similar to how we
developed in Visual Interdev, and we had significant issues doing so.
Nevertheless, we powered through them, and got the site into production.
For almost all of the problems we had, I have found articles referencing
similar, but not exactly the same issues.

The environment:
I have since established our development environment as it states in the
article found here ->
We have test/staging servers that run IIS6, and the developers all have
workstations running either XP or Win2K. In order to maintain a consistent
look and feel across the site, we developed a few layout classes, and all
pages in the site inherit one of those layouts so that developers need
concern themsleves with only the page content/design rather than worrying
about copy/pasting a bunch of layout html for every page.

The problem:
The Microsoft article suggests that developers set up a working directory
such as c:\inetpub\www\projectname on localhost so that when
testing/debugging, the developer will run the site as
http://localhost/projectname. This scenario breaks relative links when inhe
riting a layout making it impossible for developers to test interior pages.
Links to /somefile.aspx work fine on but fail on
http://localhost/projectname. In the same vein, a site-root level page that
inherits one of our layout classes works fine, but an interior file breaks
because the relative stylesheet and javascript file references, etc. fail.

i.e. /css/style.css != /css/style.css when accessed from / and
/interiorfolder respectively on a workstation, but when accessed on the
server /css/style.css == /css/style.css regardless of the folder.

The "best practices" suggested by Microsoft don't seem to work for us, and
I'm wondering if anyone has any suggestions for a solution that does not
involve re-writing the entire site ... again.

Thanks in advance for any replies.
Craig Hunt
Sr. Developer
Bright House Networks
c r a i g dot h u n t at m y b r i g h t h o u s e dot c o m



tom pester

Hi Craig,

Let me first try to solve the path problem. I know the problem and its a
pain cause we all love absolute urls in development.
On top of every page specify this : <BASE HREF="..."> Where ... is your starting
directory (can be empty if its a production site).
Some clever logic can detect on what pc its running and put the right value
there. This works for _every_ page and I hope will sovle the problem.

You are also aware of the "~" in paths? If you use that in server controls
then will make your path work.

Other solutions are Request.ApplicationPath and ResolveUrl(). Check this
post :

But the first solution I present is more transparent.

I think you always have to keep it stupid and simple. I dont know your workflow
and your willingness to try new technologies and programs.
You could be very well better off with a lightweight but solid environmonet
like Visual Web Developer Express.
It has a built in web server so it just runs without IIS (very pleasant to
work this way) and the new features of ASP.NET 2.0 provide Master Pages with
visual support in the page designer.

Let me know if it helped you or not...

Tom Pester

tom pester

BTW if you don't get it to work just ask the problem here again. I have done
this kinds of things and I know it can be a pain in the b$tt

Tom Pester



Craig Hunt

Ya know, I had forgotten all about the <BASE> tag ... duh. I had a few
other issues to address regarding server controls, but I've sinced resolved

Thanks for the reminder!

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question