By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,715 Members | 1,815 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,715 IT Pros & Developers. It's quick & easy.

ASP.NET/VSS in a multi-developer environment

P: n/a
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 ->
http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp.
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 http://mysite.com 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

Nov 19 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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 asp.net will make your path work.

Other solutions are Request.ApplicationPath and ResolveUrl(). Check this
post :
http://weblogs.asp.net/fmarguerie/ar...05/126455.aspx

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...

Cheers,
Tom Pester
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 ->
http://msdn.microsoft.com/library/de...ry/en-us/dnbda
/html/tdlg_rm.asp.
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 http://mysite.com 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

Nov 19 '05 #2

P: n/a

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

Cheers,
Tom Pester
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 ->
http://msdn.microsoft.com/library/de...ry/en-us/dnbda
/html/tdlg_rm.asp.
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 http://mysite.com 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

Nov 19 '05 #3

P: n/a
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
those.

Thanks for the reminder!
Craig

"tom pester" <To********************@pandora.be> wrote in message
news:a1**************************@news.microsoft.c om...
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 asp.net will make your path work.

Other solutions are Request.ApplicationPath and ResolveUrl(). Check this
post :
http://weblogs.asp.net/fmarguerie/ar...05/126455.aspx

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...

Cheers,
Tom Pester
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 ->
http://msdn.microsoft.com/library/de...ry/en-us/dnbda
/html/tdlg_rm.asp.
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 http://mysite.com 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


Nov 19 '05 #4

P: n/a
Well, after a couple of weeks working with the <base> tag "solution", we
discovered the hard way that the tag breaks more than it fixes - the most
egregious of which is action attributes on form tags. For example, any
interior page I have posts to a page of the same name in the root of the
site (/subdir/page.aspx posts to /page.aspx with a <base
href=http://site.com/"> tag). There are many other things broken with the
site using http://site.com or http://site.com/ as the base href. In any
case, that tactic just will not solve the problem.

Surely, we're not the only development *team* to encounter problems such as
these. I've just about burned up the google search engine trying to find a
way for us to resolve this problem to no avail. If you or anyone else has
suggestions, I'm more than willing to try them. I've got to get something
working here soon.

Thanks in advance for any replies.

Craig

"tom pester" <To********************@pandora.be> wrote in message
news:a1**************************@news.microsoft.c om...

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

Cheers,
Tom Pester
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 ->
http://msdn.microsoft.com/library/de...ry/en-us/dnbda
/html/tdlg_rm.asp.
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 http://mysite.com 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


Nov 19 '05 #5

P: n/a
We use mostly relative links, so they work both locally and on a
(test/staging/hosting) server. If you design the site so that all (relevant) files
are at the same directory depth (we use 2: /part1/part2), then you can
go from there to the approot with ../../ and continue from there.

For urls that are processed by the .Net system, there is a handy shorthand:
a leading "~" gets translated to "the root of the application", whatever
that is at the moment.

Hans Kesting
Craig Hunt wrote:
Well, after a couple of weeks working with the <base> tag "solution",
we discovered the hard way that the tag breaks more than it fixes -
the most egregious of which is action attributes on form tags. For
example, any interior page I have posts to a page of the same name in
the root of the site (/subdir/page.aspx posts to /page.aspx with a
<base href=http://site.com/"> tag). There are many other things
broken with the site using http://site.com or http://site.com/ as the
base href. In any case, that tactic just will not solve the problem.

Surely, we're not the only development *team* to encounter problems
such as these. I've just about burned up the google search engine
trying to find a way for us to resolve this problem to no avail. If
you or anyone else has suggestions, I'm more than willing to try
them. I've got to get something working here soon.

Thanks in advance for any replies.

Craig

"tom pester" <To********************@pandora.be> wrote in message
news:a1**************************@news.microsoft.c om...

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

Cheers,
Tom Pester
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 ->
http://msdn.microsoft.com/library/de...ry/en-us/dnbda
/html/tdlg_rm.asp.
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 http://mysite.com 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

Nov 19 '05 #6

P: n/a
I had the same problem, and got it working with the following code:

<LINK rel="stylesheet" type="text/css"
href="<%=Server.MapPath("~/Style.css")%>">

Nov 19 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.