ASP.NET development in Visual Studio and .svn directories.

[Kevin Pilch-Bisson <ke...@pilch-bisson.net>]

As promised, I did look into this again on Monday.  I haven't had a chance
to type up the results of looking into it again until now.

I'm going to present the results in a Q&A type format.

Q: When does this problem occur?
A: When developing asp.net projects using Visual Studio.NET, and subversion.
ASP.NET is a way of developing websites that have code which runs on the
server.  Only ASP.net is affected by this, so people developing any other
type of project should have no problems using svn.

Q: What causes the problem?
A: ASP.net projects are stored on a (possibly) remote machine, and accessed
by visual studio using Front Page Server Extensions.  There is a bug
somewhere in this dealing with path names that begin with a leading '.'.

Q: What investigation has been done before?
A: I pointed a friend on the ASP.net team to a newsgroup post about this a
while ago, and he told me that he thought it was a bug in FPSE, which I
don't have a hope of getting fixed.

Note that I did say it should be fixed in Whidbey for local filesystem
websites (which are a new Whidbey feature), because they don't use FPSE.
However, Whidbey will still allow ASP.NET projects to work against either
local or remote IIS installations using FPSE.  I expected the bug would
still be present in those scenarios until FPSE fixed it.

Q: What did you do on Monday?
A: I installed Everett on a Windows XP machine, and Whidbey on a Windows
Server 2003 machine.  Then I verified that the bug existed in Everett (not
with svn, just with a folder named .foo).  Next I did some research about
Parent Path and URLScan, and found that they won't fix the problem).  Then I
created a local filesystem website using Whidbey, and created a folder named
.foo.  This worked fine.  Next I created a local IIS website using Whidbey,
and created a .foo folder there.  This worked fine too.  Finally I created a
Remote IIS website using FPSE (the site was hosted on the XP machine with
Everett).  I created a .foo folder, and everything still worked fine.  At
that point I realized that the bug wasn't in FPSE, but was instead in Visual
Studio's code which talked to FPSE, so I emailed my friend on the ASP.net
team and asked him to take another look.

He said he will take a look, but it's currently a lower priority for him
then getting ready for the Whidbey beta, so I don't know when I'll have more
info. 

Q: What can we do now?
A: There are a several options.  1. Wait for Whidbey, which has the problem
fixed.  2. I will try to make sure the issue is considered for any service
packs that may be released for either VS.NET 2002, or 2003(Everett).  3. If
anyone has a support contract for Visual Studio, they can try talking to PSS
and getting the issue escalated and a QFE(hotfix) issued for it.  Pushes for
QFE's have to come from customers and PSS, so I can't really push this
approach.

Q: What about parent path and URLScan?
A: Parent path only affects actual Parent paths, (..) not things that have .
in the name.  Urlscan can't solve the problem for at least one and possibly
two reasons. First, FPSE is a high priority ISAPI filter, which means it
sees the paths before URLScan.  Second, the bug doesn't appear to be in
FPSE, but rather in the ASP.net project system, so I don't think it would
have any effect even if FPSE was a low priority filter.

Q: What do you think should be done about the problem?
A: Since it will be fixed in Whidbey (and possibly in Everett and 2002), I
think svn should do nothing, and continue recommending people use a custom
built client for now.

Hope that clears things up a little bit.

--
Kevin Pilch-Bisson


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: ASP.NET development in Visual Studio and .svn directories.

[Kevin Pilch-Bisson <ke...@pilch-bisson.net>]

> -----Original Message-----
> From: cmpilato@localhost.localdomain
> [mailto:cmpilato@localhost.localdomain] On Behalf Of C. Michael Pilato
> Sent: Thursday, March 18, 2004 8:43 PM
> To: Justin Erenkrantz
> Cc: Kevin Pilch-Bisson; dev@subversion.tigris.org
> Subject: Re: ASP.NET development in Visual Studio and .svn directories.
> 
> Justin Erenkrantz <ju...@erenkrantz.com> writes:
> 
> > --On Thursday, March 18, 2004 9:46 PM -0600 "C. Michael Pilato"
> > <cm...@collab.net> wrote:
> >
> > > "Kevin Pilch-Bisson" <ke...@pilch-bisson.net> writes:
> > >
> > >> Hope that clears things up a little bit.
> > >
> > > Dude.
> > >
> > > You just sussman'd us about All Things ASP.Net And .Svn.
> > >
> > > I stand amazed.
> >
> > Ditto.  Wow.  Thanks, Kevin!
> >
> > Any objections to adding Kevin's post (or a link to it) to our FAQ?
> > This thread has a really high recurrence rate, so adding to the FAQ is
> > probably warranted.  If someone else wants to commit this, be my
> > guest!  -- justin
> 
> I think if it can be tightened up a bit, it would make a *great* FAQ
> item.  Or perhaps just link to the archive URL.
> 
None from me, either way

--
Kevin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ASP.NET development in Visual Studio and .svn directories.

["C. Michael Pilato" <cm...@collab.net>]

Justin Erenkrantz <ju...@erenkrantz.com> writes:

> --On Thursday, March 18, 2004 9:46 PM -0600 "C. Michael Pilato"
> <cm...@collab.net> wrote:
> 
> > "Kevin Pilch-Bisson" <ke...@pilch-bisson.net> writes:
> >
> >> Hope that clears things up a little bit.
> >
> > Dude.
> >
> > You just sussman'd us about All Things ASP.Net And .Svn.
> >
> > I stand amazed.
> 
> Ditto.  Wow.  Thanks, Kevin!
> 
> Any objections to adding Kevin's post (or a link to it) to our FAQ?
> This thread has a really high recurrence rate, so adding to the FAQ is
> probably warranted.  If someone else wants to commit this, be my
> guest!  -- justin

I think if it can be tightened up a bit, it would make a *great* FAQ
item.  Or perhaps just link to the archive URL.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ASP.NET development in Visual Studio and .svn directories.

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Thursday, March 18, 2004 9:46 PM -0600 "C. Michael Pilato" 
<cm...@collab.net> wrote:

> "Kevin Pilch-Bisson" <ke...@pilch-bisson.net> writes:
>
>> Hope that clears things up a little bit.
>
> Dude.
>
> You just sussman'd us about All Things ASP.Net And .Svn.
>
> I stand amazed.

Ditto.  Wow.  Thanks, Kevin!

Any objections to adding Kevin's post (or a link to it) to our FAQ?  This 
thread has a really high recurrence rate, so adding to the FAQ is probably 
warranted.  If someone else wants to commit this, be my guest!  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ASP.NET development in Visual Studio and .svn directories.

["C. Michael Pilato" <cm...@collab.net>]

"Kevin Pilch-Bisson" <ke...@pilch-bisson.net> writes:

> Hope that clears things up a little bit.

Dude.

You just sussman'd us about All Things ASP.Net And .Svn.

I stand amazed.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: ASP.NET development in Visual Studio and .svn directories.

[Kevin Pilch-Bisson <ke...@pilch-bisson.net>]

Note that I should point something out here, so I don't get in trouble from
management at some point in the future.

The fact that the bug doesn't happen on today's build of Whidbey, is NOT a
guarantee that it won't happen when Whidbey is actually shipped.

I make no promises that it won't be regressed between now and then.

--
~~~~~~~~~~~~~~~~~~~~
 Kevin Pilch-Bisson
~~~~~~~~~~~~~~~~~~~~

> -----Original Message-----
> From: Kevin Pilch-Bisson [mailto:kevin@pilch-bisson.net]
> Sent: Thursday, March 18, 2004 7:13 PM
> To: dev@subversion.tigris.org
> Subject: ASP.NET development in Visual Studio and .svn directories.
> 
> As promised, I did look into this again on Monday.  I haven't had a chance
> to type up the results of looking into it again until now.
> 
> I'm going to present the results in a Q&A type format.
> 
> Q: When does this problem occur?
> A: When developing asp.net projects using Visual Studio.NET, and
> subversion.
> ASP.NET is a way of developing websites that have code which runs on the
> server.  Only ASP.net is affected by this, so people developing any other
> type of project should have no problems using svn.
> 
> Q: What causes the problem?
> A: ASP.net projects are stored on a (possibly) remote machine, and
> accessed
> by visual studio using Front Page Server Extensions.  There is a bug
> somewhere in this dealing with path names that begin with a leading '.'.
> 
> Q: What investigation has been done before?
> A: I pointed a friend on the ASP.net team to a newsgroup post about this a
> while ago, and he told me that he thought it was a bug in FPSE, which I
> don't have a hope of getting fixed.
> 
> Note that I did say it should be fixed in Whidbey for local filesystem
> websites (which are a new Whidbey feature), because they don't use FPSE.
> However, Whidbey will still allow ASP.NET projects to work against either
> local or remote IIS installations using FPSE.  I expected the bug would
> still be present in those scenarios until FPSE fixed it.
> 
> Q: What did you do on Monday?
> A: I installed Everett on a Windows XP machine, and Whidbey on a Windows
> Server 2003 machine.  Then I verified that the bug existed in Everett (not
> with svn, just with a folder named .foo).  Next I did some research about
> Parent Path and URLScan, and found that they won't fix the problem).  Then
> I
> created a local filesystem website using Whidbey, and created a folder
> named
> .foo.  This worked fine.  Next I created a local IIS website using
> Whidbey,
> and created a .foo folder there.  This worked fine too.  Finally I created
> a
> Remote IIS website using FPSE (the site was hosted on the XP machine with
> Everett).  I created a .foo folder, and everything still worked fine.  At
> that point I realized that the bug wasn't in FPSE, but was instead in
> Visual
> Studio's code which talked to FPSE, so I emailed my friend on the ASP.net
> team and asked him to take another look.
> 
> He said he will take a look, but it's currently a lower priority for him
> then getting ready for the Whidbey beta, so I don't know when I'll have
> more
> info.
> 
> Q: What can we do now?
> A: There are a several options.  1. Wait for Whidbey, which has the
> problem
> fixed.  2. I will try to make sure the issue is considered for any service
> packs that may be released for either VS.NET 2002, or 2003(Everett).  3.
> If
> anyone has a support contract for Visual Studio, they can try talking to
> PSS
> and getting the issue escalated and a QFE(hotfix) issued for it.  Pushes
> for
> QFE's have to come from customers and PSS, so I can't really push this
> approach.
> 
> Q: What about parent path and URLScan?
> A: Parent path only affects actual Parent paths, (..) not things that have
> .
> in the name.  Urlscan can't solve the problem for at least one and
> possibly
> two reasons. First, FPSE is a high priority ISAPI filter, which means it
> sees the paths before URLScan.  Second, the bug doesn't appear to be in
> FPSE, but rather in the ASP.net project system, so I don't think it would
> have any effect even if FPSE was a low priority filter.
> 
> Q: What do you think should be done about the problem?
> A: Since it will be fixed in Whidbey (and possibly in Everett and 2002), I
> think svn should do nothing, and continue recommending people use a custom
> built client for now.
> 
> Hope that clears things up a little bit.
> 
> --
> Kevin Pilch-Bisson
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org