I just upgraded to the latest Unity and I’ve tried everything I can think of. I’ve googled this, I’ve tried every combination of buttons and fixes but VS 2015 does not pause the game at a breakpoint!
I’ve installed the latest VS 2015 version (upgrade 2) and VS tools, imported it to my project, and tried attaching and playing the project. Nothing happens in the way of breakpoints.
I should mention there is no menu button in Unity for VS tools like I’ve read about. I don’t know why that is.
I generally don’t bother with break points. Or debugging from VS.
I find debugging in Unity does the job well enough most of the time. If you want a pause, simply turn on error pause and log an error. You can set up to see the value of variables of interest in the inspector.
Well, setting the inspector to debug does get you the private variables, but if you need to see locally scoped variables your SOL.
I tend to dump a bunch of Debugs to the console. Its not a painless process. But neither is exiting Unity to relaunch it from VS witht eh debugger attached.
Debug.Log is great but slow, and nothing beats actually being able to step and see what is going on (provided that you don’t freeze the editor).
You shouldn’t have to re-launch to attach, there is an “attach to process” option in visual studio that works just fine. I’m a bit too lazy to get screenshots now, but its there, I think under the debug menu.
Just tried throwing together a quick project, set up a script to spit out “Hello world!” to the debug window, and set the desired breakpoint. Then under Visual Studio I clicked “Debug” → “Attach Unity Debugger” then proceeded to select the entry for the project. Afterwards I clicked Play in the Unity editor and it stopped at the breakpoint. Hitting continue resumed execution.
I’m using Unity 5.3.4f1 with Visual Studio 2015 Community Update 1 on Windows 7 SP1 64-bit.
Huh. I’ll try it again. Its been a while since I bothered, and that was back with MonoDevelop and 4.5 free. If the system has improved since then it may be worth revisiting.
You don’t need to import anything into your project anymore for it to work. That makes me think maybe you stumbled upon an older version of VS tools for Unity? That might mess something up.
Click on a line of code one time and press Ctrl-B. Conditional breakpoints are invaluable, especially when debugging inside of loops. Also watches and quick watches, etc. By just dumping logs to the console you are missing out on a wealth of great debugging tools.
In your project settings in Unity… is it set to Debug? They may only affect builds, I’m not sure.
@Dustin-Horne yes, it is set to debug. It wasn’t working with VS tools outside the project (not imported) which is why I tried that.
But do you guys know whats REALLY odd? It works now. IDEK what I did to make this work.
Im so used to finding bugs without debugging now I dont need a debugger.
(and its not because there are so many or they are easy to find - its because I work with 8 million SLOC piece of software that refuses to be debuggable - you can hit a breakpoint, but if you dont continue in about 5-10 seconds the whole app will start hitting deadlocks and become unreliable… thats assuming you can even view the value youre inspecting within that time frame)
The other software is a flight sim, so again that has to be debugged without running the code on my machine… take it to machine, try it, fixed? repeat… its an ass of a process.
debugging is overrated 
Sounds like your app should be componentized into multiple “services” (services here meaning logical, not web services) that can be implemented and tested independently. Modularization would be your friend there.
I guess I’ll ask here, what is the difference between doing this and just using Debug.Break(); somewhere in your code?
Breakpoints are basically a way of pausing execution of the program when it has reached a certain point. It can be set to happen every single time execution reaches the point specified or it can be set to only happen if a variable is in a certain state when that point is reached. Once execution has been paused you can see the current state of variables, the call stack, etc.
This short tutorial can show you how to set them up.
They also do a lot more cool stuff as @Dustin-Horne pointed out above(conditional break, walking the stack/heap, object status, etc)
I see a ton of Unity developers neglecting to use proper debugging tools. Debug.Log() is not an effective solution for serious issues.
For anyone who doesn’t know about breakpoints, there is a series in Unity Learn about the topic. I suggest you also watch them, it’s an incredibly powerful tool.
I like the idea, but I also know it will never ever happen.
That’s military software for you.
Its all in VS2005. lol. You can do some debugging in later versions of VS, but upgrading the project to Windows 7/VS2015 is a cluster f*** in its own right. Can anyone say 6 months of testing! Yeah… nah.
Ahhh very cool. I had accidently popped those breakpoints up before in vs and kinda wondered what that was about, but never actually looked into it, and have always been using unity specific debug stuff… Thanks @Ryiah for sharing that!
And to think how useful this would have been to know a few times over the years… doh
Is there somewhere to sign up to be notified when new video tutorials are released that I’m not aware of? Because it feels like everyone else knows about these before I do. I’ve linked the video tutorial you are referring to below.
I am also one of the biggest advocates of the learn section. And I didn’t see this one when it was released.
In fairness its hosted on the Microsoft Visual Studio channel, instead of the Unity one. I’m a subscriber to the Unity one, so I see new videos there. But I wouldn’t have expected the Visual Studio channel to be hosting new learn section videos. Apparently there is a whole section on visual studio that’s not hosted on the regular channel.