At the current moment, what I'm doing is that I'm opening Unity, double click on one of those scripts I've written, then MonoDevelop gets opened, now I have to close unity and in MonoDevelop I do Run >> Run with >> Unity Debugger.
After this Unity gets opened and when I press the play button in unity the debugging session starts. But once only. If I stop this session in either Unity or MonoDevelop I have to repeat this whole procedure all over again, which is very tedious. I have to open Unity, close Unity, (I have to close it because next step which is Run >> Run with >> Unity Debugger will open unity and if unity is already opened I'm getting error saying that only one instance of unity can open one project at a time).
What I'm asking is:
Is there any better workflow which would free me from this tedious switching on and off Unity, and every time I stop debugging session I would just start normally without doing these tedious repetitions?
Use 'Attach' in MonoDevelop's debug menu; you should be able to attach to the running Unity process that way. (You may need to ensure that the appropriate option is turned on in Unity's preferences).
Another way to debug is by using the:
Debug.LogError("foo");
or
Debug.LogWarning("foo");
Another note is that you can actually bind objects to the Log. This will cause the editor to highlight the object is question in the event you are iterating over a list of GameObjects. i.e.:
Debug.LogWarning("this object broke", gameObject);
If you turn on "Error Pause" in the console window, the game will automatically pause when the LogError is met. But be warned, it will pause whenever an error is thrown.
I've always changed the default script editor (unity preferences -> external tools -> external script editor) to visual studio. This lets you use breakpoints and preprocessor macros to make debugging much easier. When you want to start debugging press f5 in visual studio to connect it to unity then play like normal and if a breakpoint is hit visual studio takes over.
You don't have to change anything else and you won't have to keep opening and closing things like you are now.
UnityVS is now officially part of Microsoft and is available as an add-on for vs 2010,12 and 13. Here's the MSDN blogpost linking to the various versions: http://blogs.msdn.com/b/visualstudio/archive/2014/07/29/visual-studio-tools-for-unity-1-9.aspx
Do you know about the Unity "Console" window? You should be able to open it from Menu/Windows/Console. It will act as a debugger giving you errors and warnings both while pre-compiled and at runtime. If I misunderstood the question, let me know.
Recently, Microsoft Acquired SyntaxTree, the creator of UnityVS plugin for Visual Studio, so it is going to get released for free very soon. UnityVS is a must-have plugin for every Unity3D developer, due to it's productivity and the ability or debugging of Unity3D games in Visual Studio.
http://unityvs.com/
In MonoDevelop, there's a button near the top of the window that says "attach to unity". If you do this before you play your scene, any breakpoints set in MonoDevelop will halt the main thread there.
If you're just trying to inspect values, Debug.log(message) prints data directly to unity console.
Both of these can be used while in regular play mode.
Easiest way to debug is using Debug.log("");
but this does cost you your performance so how can you debug easier?
well here is the answer:
To start debugging, press your mouse to the far left edge of the editor (next to the line number) and a red dot will appear, you would have just created a breakpoint!
This will not do anything for now, however, if you now go to Unity and press play in your editor window something great will happen…
At the very bottom of the window, if you have the locals window open (if not, Go to View > Debug Windows > Locals), you will see all of the variables that currently exist in the local instance and their values at the time of the breakpoint being hit.
To continue the applications execution, just press the “Play” button in MonoDevelop.
Your script will continue its execution (and Unity’s editor will no longer be frozen). Of course in this instance, the script will hit the breakpoint again on the next frame. So just left click the breakpoint in MonoDevelop and hit the Play button again so it doesn’t execute the breakpoint again.
You can do more things with it for example:
With breakpoints, you can make them stop the application running when certain conditions are met. For example, imagine you want to check what the values are when the fSpeed variable reaches 10. To do that, press the Stop button in MonoDevelop, and Right click on your breakpoint, then press Breakpoint Properties.
Set the condition to “Break when condition is true” and set the “Condition Expression” to “fSpeed >= 10” and then press OK.
Re-attach the editor to Unity and press the Play button in Unity, when the condition is met the breakpoint will fire and stop the application.
A note about using Condition Breakpoints: They cause performance issues as it has to validate the expression each time it is run.
this should in general be better then debug.log(""); atleast if this is what you desire.
The best way using Debug.Log() for debugging in Unity if your problem is suitable to apply this.
I'm using the plugins UnityVS, which can debug Unity projects with Visual Studio.
Very convinient.
Have a google with UnityVS
You could check out using MS Visual Studio Community and getting the Unity integration they also provide on their website. I recently tried it and it's great, you get pretty much full debugging functionality using one of the best IDE available. Paired with Unity you can get some nice productivity boosts, not just in terms of debugging capabilities, but also in terms of feature set.
In case you want to check it out, here is a link to the Community version of the IDE: https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx
Here is also a link to the Unity integraiton I mentioned: https://www.visualstudio.com/features/unitytools-vs
Hope it helps, a fellow developer converted me from Mono and honestly I couldn't be any happier with that setup (unless some IDE integrates the "make it work" button once and for all ;) ).
With Unity 5.5 visual studio tools are built in, you can attach unity and start debugging with a single click
i.e after Edit > Preferences > External tools > External script editor > Visual studio
There are two ways of debbuging in unity once is by Log which is console basically within Unity and the other is Debugger which is VS and Mono both supporting .
Yes you are right its very awfull process to check by debug point tha what is the value of a and b etc
so here is my opinion that use only what is best suiteable for you i mean you do not need of debugging point for just know the value of a and b just log it.
and when there is need for debugging point you already know the method.
You can use the Run button (looks like a play button in the top left) to connect to the Unity Editor for debugging, but if you're not connecting to Unity successfully this way, you may want to check that the appropriate plugin is enabled in your Add-in Manager preferences.
Windows:
Tools > Add-in Manager > Unity > Mono Soft Debugger Support for Unity
OSX:
Unity > Add-in Manager > Unity > Mono Soft Debugger Support for Unity
(Select and click enable.)
use debug.log("Message"); for debugging
Something I like to do too is making shortcuts for logging useful data within the Unity Editor. For example logging the current state of all my active achievements.
[MenuItem("My Game/Runtime debug/Achievement states")]
public static void LogAchievementStates ()
{
foreach (AchievementState achievementState in Data.achievementStates)
{
Debug.Log ("Achievement " + achievementState.name + " is at " + achievementState.completion + "%");
}
}
Doing this within an editor script will display a menu button to run certain actions.
I think that what the question is after, is a way to launch a "unity built game executable" and attach the debugger to it.
Something like...
creating debugging symbols with gcc, building the application with DEBUG enabled and launching the executable program with gdb to debug it. That way you can launch debugging sessions without using an IDE. But that's in C using gcc... in C# there is no need for debugging symbols for the attached debugger to see the code and it runs over a virtual machine.
There is an open conversation about how this can be done here:
https://github.com/0xd4d/dnSpy/issues/393
Some quick notes for someone not versed in virtual machine languages. C# produces an intermediate language when compiled. Contrary to C for instance that produces machine code, executed directly by the CPU. In the case of C# this intermediate language is call Common Language (because it is common for all .NET languages like VB.NET, C#.NET and C++.NET. This intermediate language is not executed by the CPU directly but by a virtual machine instantiated once per application or process, which is called the CLR (Common Language Runtime). This means that most of the time, if the variables and methods are not replaced by gibberish (which is called obfuscating), the program can be read directly by a debugger attached to the executable.
According to the conversation, the unity engine does not use the .NET CLR but a separate (potentially modified) CLR embedded to the engine. They do describe ways to do that but, I think its safer and easier to use the Unity Editor.
Unity is built around the editor anyway! For instance, within the editor context, you can change public variables and references while playing the game, which is not a "classic" programming approach. But it is a classic debugging approach.
Lastly, there are stuff like the threads of the program that are not open sourced, so I doubt that any external tool would be able to find its way around the code. Even if, it is pure Common Language, which I seriously doubt because if it was pure CL there would be no need for a separate (potentially customized) CLR to be including in the engine.
The whole misunderstanding in my opinion, is caused by the fact that the language that Unity is using, is not exactly C#, but a unity-variant that looks like C# and it may be compatible with C# but I do not know to what degree. So, the "CLR" you are programming in Unity is actually the unity engine itself. A "CLR" focused on rendering games in many platforms and not the classic C# CLR.
About the other answers:
- MonoDevelop lets you use breakpoints and preprocessor macros just as well as any other IDE.
- As for the text debugging using the log. Of course its possible but this is what one does when "real debugging" is not available.
tried visual studio? there you can attach the scripts to unity and debug them.
First you have to attach the C# code present in monodevelop or visual studio to the Unity debugger, than press the play button in the IDE monodevelop and than in last play it on unity.
You can just put some print() or something idono
Just try to open the C# scripts with Visual Studio you want to debug Use Visual Studio 2017 for this purpose and just start the project with debugger and apply breakpoints on your desired location and run the project . I think it will solve you issue and debug the desired piece of code
Unity documentation -- Debugging C# code in Unity provides the complete methods to debug the C# code in the editor and in the player.
Is there a way to prevent Visual studio to start the debugger when pressing F11? I often press it by mistake when I want to actually press F12.
I do not want to loose the functionality of Step-into which F11 provides but it is annoying when it starts the application.
This is for VS 2010, but it should be similar for others.
In Tools->Options, open Keyboard under Environment. Look up the command Debug.StepInfo. You can remove the default shortcut (F11 (Global)) and then just use the toolbar button to step into, or right click and "Step into specific"--which is what I do since it keeps the debugger from diving into STL functions if they're part of a line of code (as an example).
A hack-around that I use is to use the cancel build command after I accidentally hit F11. The default shortcut is ctrl+pause/break.
This doesn't stop F11 starting a build, but should stop it from running your program.
This is the suggestion on Microsoft's VS Community forum. Currently there is a suggestion from MSFT (I assume official MS dev?) that points to this free extension Tweaks:
Don't start debug on F10/F11 Inspired by the suggestion Please provide
a way to disable F10/F11 until debug mode is entered.
F10 (Step Over) and F11 (Step Into) are two commands people often hit
by accident. That starts a new debugging session and that can be
annoying if you didn't mean for that to happen. They should only take
effect during a debug session.
Install Resharper and Change the Key Short Settings
The question itself is in the title. See screenshots.
When I'm using those both shortcuts, my Visual Studio 2010 does exactly the same action (debug tests). However, the shortcuts are assigned for different buttons.
What am I missing?
UPDATE:
Here is my keyboard customizations in "Tools" - "Customize" - "Keyboard".
There is no difference, VS treats Ctrl+R,Ctrl+D and Ctrl+R,D as the same command. There's ancient history behind this behavior, going all the way back to an old text editor named Wordstar. Which used control key chords like that. Also adopted by Borland, a company that Microsoft was fiercely competitive with. And by me, I still use it, got a weird left pinky to show for it.
You'll have to assign a different chord for the other command.
The difference is that when using CTRL+R, CTRL+D, the test runner runs the tests with the debugger attached.
This means that you can set breakpoints in the tests and step through the code. It is very useful at times.
EDIT: I think I missed the fact that you probably know about the concept of debugging tests. As Fishermaen points out, the shortcuts might be messed up. Do you have Resharper or any other 3rd party tool that alters these settings perhaps?
Check in "Tools" - "Customize" - "Keyboard" if the shortcuts are wired up correctly.
This might have very obvious solution but I'm afraid I cannot find out how to disable this specific page which pops up each single time I use the break command whilst debugging. Every time I have to close it because I don't need it; moreover, it pops up any next time I use the break command on the toolbar.
I'm using Visual Basic Express Edition 2010
How can this be disabled?
Thanks.
Just don't use Debug + Break All. It is typically useless anyway because it is pretty unlikely that you'll break your own code. Which is what the window is telling you. Set a breakpoint on a line of your own code, the code you want to debug or verify. Clicking in the left margin will set one.
Does anyone know where can I enable the bar that let me switch between different views (Design,split,..) in Visual Studio 2010 ? I can't find it and it is not enables by default
If you go into the Visual Studio Tools -> Options menu, under HTML Designer -> General there is a checkbox to enable or disable the HTML designer. Checking this and restarting VS will do the trick and show the Design/Split/Source options at the bottom again.
I really prefer the Code Optimized setup but do need on occasion to hit the design view, shame it does not seem easier to expose and, when exposed, takes up more UI than it really needs to.
Do you have the Design/source tabs down in the bottom left corner of the window? (just above where your debug & immediate windows appear from in the default view). If you do, look further to the right of them, there is a splitter bar you can drag up to produce the split mode.
It's a corrupt installation, try reintall the VS
I also cannot see the Design/Source tab split. I could have sworn it was in VS2010 RC. Did they take it out of retail?? (I'm working with an Activity xaml file)
go to Tool->Option->General->Enabe Html Designer