Anyone notice how .net still runs code after you hit "stop"?
 

(Sorry, worded the subject wrong... should be "the Visual Studio .net 2003 Debugger" instead of plain ol' ".net")

What's up with this?

Say you breakpoint a line and have some code underneath that inserts a few records into a table in a database.

Lines go somewhat like this:

init variables
open db connection
insert records
close db connection

If you breakpoint on the init variables part and step through the code and realize "oh, I just spotted an error in my code" and hit stop, all the code beyond that is still executed, or in this case, records will be inserted into the table.

Why does it do this? Isn't that potentially dangerous in the sense that even though you spotted the error and hit stop, your code will still follow through?

Basically it kinda sucks for me right now because I need to run this app and breakpoint it to see how data will look before going in, but in order to prevent it from actually executing the SP, I have to rename it on the server so when it's called, it errors out.

I know for a fact that VB 6, nor VC++ 6 did not do that.

So I guess this is another testament to how badly .Net sucks. Why do you use .Net BTW?

How would that be a testament to how bad .net sucks? The Visual Studio Designer is making this error, not the framework.

I use .net because it's a great development platform and is better than anything I've used before (and I've used all of em, including java)

I've been writing apps similar to what your describing for about a year now with VB.NET, and I've never experienced what you are describing. When I stop the exe, especially at a breakpoint, the code stops...nothing more, nothing less.

I've been working with the .NET framework since it was in beta (off and on) and I've never seen that in VS 2K2 or 2K3. Are you sure you are stopping the code? If it's really a problem you can just comment out the line that does the DB insert while you are debugging.

I'll make a quick example once I have a few extra minutes to do so.

I'm surprised no one else has experienced this. The other programmers I work with have also experienced this.

I assumed garbage collection would run after you stopped your code, but for your code to keep executing after you hit stop just doesnt make sense.

Are you sure your stopping where you think your stopping? Place a break point near the start of execution and step through your code to make sure you are where you think you are.

Load up a new asp.net project.

Add a button to the default webform and add the following code to the click event (don't forget to include "using System.Data.SqlClient;" at the top):

Breakpoint the line "cmd.ExecuteNonQuery();"

When the debugger reaches that point, hit stop. Look in your northwind database and you will see a category called "test". Even if you breakpoint on conn.Open(), the category is added.

This does it on all of my development machines (4), so I don't think it's a botched install.

[edit]
I just tried this in a plain old windows forms application and there is no bug, so perhaps it's an error in the asp.net worker process.

What happens if you comment out the line "cmd.ExecuteNonQuery();"

Have you put a trace on the database using SQL profiler and see what code is being sent?

If you comment it out, nothing will happen, of course, since that's the statement that actually executes the SQL code. I mean, you won't see proof of code still executing unless you check connection logs to see that the db connection was in fact opened, but code is still being executed regardless.

And I'm not sure about what you're asking regarding the trace... the same exact code is being sent as if you were to execute the click event without any breakpoints.

The designer is basically ignoring the fact that you hit "stop" and is executing the code regardless.

Did any of you try it? If so, what were the results?

I'll try it Monday at work (I only do WinForm development here at home. Just little applications for myself). But I do that exact kind of code almost every day and I've never had a problem with code executing after I've hit "stop" in the debugger. You say "If you comment it out, nothing will happen, of course," but if you hit stop when you have a breakpoint set on that line that line shouldn't execute of course. This tells me that you're doing something differently than I do when I'm debugging. So you set a breakpoint and the code stops, do you hit F5 then or click the "stop" button in the debugger? If you set a breakpoint at the event handler declaration "private void Button1_Click(" and then run the code, stopping when you get to the event handler, does the SQL statement still get executed? How are you stopping execution of the code? When you hit the breakpoint and step through the code using F11 what happens? I'm taking you through the same kinds of steps I would use if I ran into this problem.

You can use the SQL Profiler to start a trace and watch the activity on a specified database. That'll show you the SQL being executed against the database and when it is executed.

If you breakpoint the conn.Open() AND the cmd.ExecuteNonQuery() statements, once you hit stop in the debugger (by clicking the "stop" button on the toolbar), the code will still execute. To me, this shows that it's something in the background, and since it only happens on asp.net projects... I can only assume the worker process.

I had a friend of mine try this on his machine and it does the same thing to him.

It's funny that no one has experienced this, because I've been dealing with this issue for AGES now and I'm starting to get pretty fed up with it :)

Anyone try the code example yet?

... or are you just as stumped? ;)

argh, I've been in meeting hell for the past two days! Tomorrow I'm chaining myself to my desk though so I'll try it then. I saw a post on a blog somewhere today talking about this exact problem (was it you?) and the solution was some setting like "debug unmanaged code = true" which seemed odd to me since I thought the ASP.NET process was all managed code.

I'll try it out and try debugging it with WinDbg to see if I see the same behavior.

wow, when I first read this i thought you were on crack..but tried it on a project that I am working on and it definitely happens... If i break on my connection.open statement and hit stop then the query isnt executed..but if i step past that to the next line (cmd.connection = conn) and stop, it continues on and executes the query... very odd.

This is just another part of server-side programming.

I've written plenty of scripts in the past that looped longer than I wanted. Even when I hit stop, the server was still going.

The problem lies within the engine over on the server. If you are legitimately stopping your app and the server is still crunching numbers, then I'd say something is definately up with .NET (this would not surprise me at all)

It's on the same machine (local XP Pro). I'm not doing remote debugging or execution of any kind.