VS2005 Executes Code After I Hit Stop

[ohnoonho]

Hello,

I posted this in the C# group but thought maybe the better place would
be here since it is happening with website projects so please forgive
any cross posting.

In my website projects I can set a breakpoint, run the app, the
breakpoint gets hit, and I can step through or check some variables or
what not, and if I hit stop it appears that the rest of the method (and
any calling method) continues to execute. I know this because there are
sql calls being made (though they are on lines well after the line I
was on when I hit stop) and I can check the database and see that rows
were inserted/updated. As you can imagine, this is quite frustrating as
the whole reason I hit stop is that I *didn't* want to continue to do
work against the db. This never happened in VS2003 and only started
happening in VS2005 last week (I've been developing with it for several
months now).

Anybody else seen this? Any ideas are appreciated.

[dgk]

On 21 Jun 2006 10:11:30 -0700, oh******@hotmail.com wrote:

Hello,

I posted this in the C# group but thought maybe the better place would
be here since it is happening with website projects so please forgive
any cross posting.

In my website projects I can set a breakpoint, run the app, the
breakpoint gets hit, and I can step through or check some variables or
what not, and if I hit stop it appears that the rest of the method (and
any calling method) continues to execute. I know this because there are
sql calls being made (though they are on lines well after the line I
was on when I hit stop) and I can check the database and see that rows
were inserted/updated. As you can imagine, this is quite frustrating as
the whole reason I hit stop is that I *didn't* want to continue to do
work against the db. This never happened in VS2003 and only started
happening in VS2005 last week (I've been developing with it for several
months now).

Anybody else seen this? Any ideas are appreciated.

That's interesting. I'm using a database called Cache and it seemed
that in debugging a website some data got written that wasn't supposed
to because I hit the square Stop Debugging button. This is VB in
VS2005. It seems like a line did execute that wasn't supposed to.

The way the Cache DB works is very different from SQL Server in that
I'm actually using a proxy object that is linked to the real object in
the Cache DB, not rows in a table. So I was setting properties on that
object but not executing the Save method which was a good three or
four lines further in the code. However the changed property values
were being persisted in the DB even though Save hadn't been hit yet.

I called up InterSystems (the Cache vendor) and spoke to a support guy
about it but then I couldn't duplicate it. So I assumed that it was
sunspots. But now you come along and claim that VS continued executing
code after stopping and that matches exactly what I saw.

Perhaps it has something to do with Finally? That code is supposed to
execute no matter what. Did you have a Finally involved somewhere?

[ohnoonho]

The only thing the finally does for me is close the database
connection. So if it was the finally being run the only thing that
should happen is that the connection closes with no work being done.
BTW, when stepping through the debugger and you hit stop the finally
shouldn't run. At least, it never did in VS2003. A friend of mine had
said that VS2005 is much more threaded than previous versions and that
sometimes causes all sorts of weirdness so we thought that might have
something to do with it but I really hope not.

Also also, I'm in now way dinging VS2005. I think MS made a great tool
even better. I just wish I could figure this problem out and fix it.

dgk wrote:

On 21 Jun 2006 10:11:30 -0700, oh******@hotmail.com wrote:

Hello,

I posted this in the C# group but thought maybe the better place would
be here since it is happening with website projects so please forgive
any cross posting.

In my website projects I can set a breakpoint, run the app, the
breakpoint gets hit, and I can step through or check some variables or
what not, and if I hit stop it appears that the rest of the method (and
any calling method) continues to execute. I know this because there are
sql calls being made (though they are on lines well after the line I
was on when I hit stop) and I can check the database and see that rows
were inserted/updated. As you can imagine, this is quite frustrating as
the whole reason I hit stop is that I *didn't* want to continue to do
work against the db. This never happened in VS2003 and only started
happening in VS2005 last week (I've been developing with it for several
months now).

Anybody else seen this? Any ideas are appreciated.

That's interesting. I'm using a database called Cache and it seemed
that in debugging a website some data got written that wasn't supposed
to because I hit the square Stop Debugging button. This is VB in
VS2005. It seems like a line did execute that wasn't supposed to.

The way the Cache DB works is very different from SQL Server in that
I'm actually using a proxy object that is linked to the real object in
the Cache DB, not rows in a table. So I was setting properties on that
object but not executing the Save method which was a good three or
four lines further in the code. However the changed property values
were being persisted in the DB even though Save hadn't been hit yet.

I called up InterSystems (the Cache vendor) and spoke to a support guy
about it but then I couldn't duplicate it. So I assumed that it was
sunspots. But now you come along and claim that VS continued executing
code after stopping and that matches exactly what I saw.

Perhaps it has something to do with Finally? That code is supposed to
execute no matter what. Did you have a Finally involved somewhere?

[Greg9Strat]

I have the same problem. I'm using VS2005 Std. Ed. and while
debugging, even though you press 'stop', the code continues to execute,
writing to the database. I have the Try/Catch statements (but no
Finally)... very annoying when you're trying to test something.

My database server is remote, but debugging is always locally
processed, so I hope this gets fixed in future releases.