You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Matthew Hawkins <da...@gmail.com> on 2006/02/27 04:39:02 UTC
SVN_ASP_DOT_NET_HACK
Hello subversion developers,
I'm not subscribed so please CC me on any responses. A colleague pointed
out to me today that this workaround is unnecessary.
Apparently what Visual Studio .NET is looking for is the presence of the
"Bin" directory inside the webservice. This is not there until the solution
is built, and unfortunately VS.NET has a chicken & egg bug where the
solution won't load (ie, directly after a checkout from svn) unless the dir
is there, and the dir isn't (normally) there until the solution is loaded &
built ;)
He always uses subversion with the regular .svn directories and has simply
made the Bin directory any time VS.NET has complained, and has never had any
problem.
If this can be shown to always be the case (I've only tested it successfully
here) then perhaps this is a better thing to do than the ugly hack which for
some clients (eg, tortoisesvn) requires a system reboot; automatically
create the Bin directory if a VS.NET web service is detected on checkout.
Cheers,
--
Matt
Re: SVN_ASP_DOT_NET_HACK may be unnecessary?
Posted by Jody Shumaker <jo...@gmail.com>.
On 28 Feb 2006 17:05:52 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> "Matthew Hawkins" <da...@gmail.com> writes:
> > Hello subversion developers,
> >
> > I'm not subscribed so please CC me on any responses. A colleague pointed
> > out to me today that this workaround is unnecessary.
> > Apparently what Visual Studio .NET is looking for is the presence of the
> > "Bin" directory inside the webservice. This is not there until the solution
> > is built, and unfortunately VS.NET has a chicken & egg bug where the
> > solution won't load (ie, directly after a checkout from svn) unless the dir
> > is there, and the dir isn't (normally) there until the solution is loaded &
> > built ;)
> >
> > He always uses subversion with the regular .svn directories and has simply
> > made the Bin directory any time VS.NET has complained, and has never had any
> > problem.
> >
> > If this can be shown to always be the case (I've only tested it successfully
> > here) then perhaps this is a better thing to do than the ugly hack which for
> > some clients (eg, tortoisesvn) requires a system reboot; automatically
> > create the Bin directory if a VS.NET web service is detected on checkout.
>
> I've changed the subject to get some more people's attention.
>
> Is it possible to detect this on checkout? We could just create the
> "Bin" directory ourselves, then, yes.
>
The problem was never solved as easily as creating a bin directory
when I ran into it. If this is a solution for you, then why not just
add the Bin directory to the repository. This would accomplish the
same thing and not require code to cover some specific case. It makes
no sense for this to be a subversion feature to cover up a vs2003 bug.
- Jody
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
SVN_ASP_DOT_NET_HACK may be unnecessary?
Posted by kf...@collab.net.
"Matthew Hawkins" <da...@gmail.com> writes:
> Hello subversion developers,
>
> I'm not subscribed so please CC me on any responses. A colleague pointed
> out to me today that this workaround is unnecessary.
> Apparently what Visual Studio .NET is looking for is the presence of the
> "Bin" directory inside the webservice. This is not there until the solution
> is built, and unfortunately VS.NET has a chicken & egg bug where the
> solution won't load (ie, directly after a checkout from svn) unless the dir
> is there, and the dir isn't (normally) there until the solution is loaded &
> built ;)
>
> He always uses subversion with the regular .svn directories and has simply
> made the Bin directory any time VS.NET has complained, and has never had any
> problem.
>
> If this can be shown to always be the case (I've only tested it successfully
> here) then perhaps this is a better thing to do than the ugly hack which for
> some clients (eg, tortoisesvn) requires a system reboot; automatically
> create the Bin directory if a VS.NET web service is detected on checkout.
I've changed the subject to get some more people's attention.
Is it possible to detect this on checkout? We could just create the
"Bin" directory ourselves, then, yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: SVN_ASP_DOT_NET_HACK
Posted by Arlie Davis <ad...@stonestreetone.com>.
> Yes ;-) The logic would go: If there is an .asmx and
> web.config file being checked out in the same directory,
> create a Bin dir if none (will) exist.
That sounds horrid. Why not simply check in the "bin" directory?
-- arlie
________________________________
From: Matthew Hawkins [mailto:darthmdh@gmail.com]
Sent: Tuesday, February 28, 2006 8:17 PM
To: dev@subversion.tigris.org
Subject: Re: SVN_ASP_DOT_NET_HACK
On 3/1/06, Branko Čibej <br...@xbc.nu> wrote:
Matthew Hawkins wrote:
> He always uses subversion with the regular .svn directories and
has
> simply made the Bin directory any time VS.NET <http://VS.NET
<http://VS.NET> > has
> complained, and has never had any problem.
Which version of VS.NET are we talking about? We've been told the
problem went away with VS.NET 2005, but is there in earlier
versions.
Sorry, I should have been clearer. I'm using 2003.
> If this can be shown to always be the case (I've only tested it
> successfully here) then perhaps this is a better thing to do than
the
> ugly hack which for some clients (eg, tortoisesvn) requires a
system
> reboot; automatically create the Bin directory if a VS.NET
> <http://VS.NET> web service is detected on checkout.
Um. Sorry, I'm dense -- do you expect Subversion to detect VS.NET
web
services?
Yes ;-) The logic would go: If there is an .asmx and web.config file being
checked out in the same directory, create a Bin dir if none (will) exist.
However, I appreciate that if this problem has been resolved in a newer
version of Visual Studio then there's little point in switching to a
different workaround - just wait for everyone to upgrade & deprecate the
hack altogether. I just wanted to pass on that there could be another way
to work around this problem, retaining normal filesystem namespace &
compatibility.
Cheers,
--
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN_ASP_DOT_NET_HACK
Posted by Matthew Hawkins <da...@gmail.com>.
On 3/1/06, Branko Čibej <br...@xbc.nu> wrote:
>
> Matthew Hawkins wrote:
> > He always uses subversion with the regular .svn directories and has
> > simply made the Bin directory any time VS.NET <http://VS.NET> has
> > complained, and has never had any problem.
> Which version of VS.NET are we talking about? We've been told the
> problem went away with VS.NET 2005, but is there in earlier versions.
Sorry, I should have been clearer. I'm using 2003.
> If this can be shown to always be the case (I've only tested it
> > successfully here) then perhaps this is a better thing to do than the
> > ugly hack which for some clients (eg, tortoisesvn) requires a system
> > reboot; automatically create the Bin directory if a VS.NET
> > <http://VS.NET> web service is detected on checkout.
> Um. Sorry, I'm dense -- do you expect Subversion to detect VS.NET web
> services?
Yes ;-) The logic would go: If there is an .asmx and web.config file being
checked out in the same directory, create a Bin dir if none (will) exist.
However, I appreciate that if this problem has been resolved in a newer
version of Visual Studio then there's little point in switching to a
different workaround - just wait for everyone to upgrade & deprecate the
hack altogether. I just wanted to pass on that there could be another way
to work around this problem, retaining normal filesystem namespace &
compatibility.
Cheers,
--
Matt
Re: SVN_ASP_DOT_NET_HACK
Posted by Branko Čibej <br...@xbc.nu>.
Matthew Hawkins wrote:
> Hello subversion developers,
>
> I'm not subscribed so please CC me on any responses. A colleague
> pointed out to me today that this workaround is unnecessary.
> Apparently what Visual Studio .NET is looking for is the presence of
> the "Bin" directory inside the webservice. This is not there until
> the solution is built, and unfortunately VS.NET <http://VS.NET> has a
> chicken & egg bug where the solution won't load (ie, directly after a
> checkout from svn) unless the dir is there, and the dir isn't
> (normally) there until the solution is loaded & built ;)
>
> He always uses subversion with the regular .svn directories and has
> simply made the Bin directory any time VS.NET <http://VS.NET> has
> complained, and has never had any problem.
Which version of VS.NET are we talking about? We've been told the
problem went away with VS.NET 2005, but is there in earlier versions.
> If this can be shown to always be the case (I've only tested it
> successfully here) then perhaps this is a better thing to do than the
> ugly hack which for some clients (eg, tortoisesvn) requires a system
> reboot; automatically create the Bin directory if a VS.NET
> <http://VS.NET> web service is detected on checkout.
Um. Sorry, I'm dense -- do you expect Subversion to detect VS.NET web
services?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org