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

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