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.
Related
Regular Visual studio has this nice feature. I don't think it is available in VS Code.
When a breakpoint hits you can jump right to bebugging (pressing f5,f10 etc) without having to click on the IDE first. I love this feature. Does anyone know if VS Code supports this as well?
I think it is supposed to focus the vscode window. There is this setting:
Debug : Focus Window on Break
which is enabled by default. But see https://github.com/microsoft/vscode/issues/80441 and https://github.com/microsoft/vscode/pull/77213 it looks there are issues.
It doesn't work for me either on Win10. I added my example to https://github.com/microsoft/vscode/issues/105913. You may want to do the same.
I've got a really pesky problem. When writing a C# application using the .NET 4.0 framework and Direct3d for managed code, and creating a device inside a user control (so that I can use it as a kind of viewport), my visual studio 2010 starts "lagging" after the first compile of it. When I type something, there is a delay about 0.5s - 1s until the typed text is shown. The same delay occurs while scrolling via page down or page up or arrow keys. With other projects which are even bigger - with up to 1000 source files (C++), or other C# projects - there is no problem like this. Mouse interaction also delays for 0.5s - 1s.
So my question is what could cause this problem and how can I avoid it?
EDIT: One more hint is that I often get by compiling it:
Unable to copy file "obj\x86\Debug\Direct3DTest.exe" to "bin\Debug\Direct3DTest.exe". The process cannot access the file 'bin\Debug\Direct3DTest.exe' because it is being used by another process.
You probably have your UserControl in design view opened either in it's own document or embedded in your form. This probably causes a DirectX device to be created inside VS. Check fi that's the case and if so you should be able to find out if your control is in design mode (in VS) or in runtime mode.
I believe there is a setting (or combination of settings) in Visual Studio that allow you to see in the Immediate Window (or Output Window, I can't remember which), the timestamp and name of an assembly as it is loaded while debugging. I used to have this switched on as it is very useful for finding performance issue areas. Sadly however, when VS recently decided to undock all my windows for no good reason, I had to reset my VS settings and have now lost this.
I can't find for the life of me which setting it was that I had switched on.
Any help appreciated.
Apart from reading Debug output messages in Output window, you can also use Modules Window (at least in Visual Studio 2013) which gives you a nice searchable list of loaded modules with various additional details:
Debug -> Windows -> Modules
In the Output window, change the "Show output from" combo to Debug if necessary. Right-click the window and tick "Module load messages". And any others you might want to see.
I still have to use the VB6 IDE.
Unfortunately every time I start the IDE one of the buttons of the toolbar disappears. Almost always it's the Run button which goes first. Sometimes also items from the menu bar or the context menus are missing.
I have to reset the toolbars almost every time I start the IDE (Which is quite often during a typical work day). Recently I bought an IDE plugin which modifies the menu bar and requires a restart after every reset of the menu bar. (Otherwise it would crash)
I could live with just the resetting, but the restart is really annoying.
Is there something I can do?
To solve this problem:
Unload all add-ins.
Right-click on a toolbar and select the Customize... menu.
For each toolbar click the Reset... button (6 times in total).
Reload the add-ins.
For me action 3 was enough.
cf. MZTools faq (thanks to Andrea Bonafini), but these steps are originally from MSDN
It sounds like you recently bought a bad add-in. Can you get your money back? Every time I've had problems with disappearing controls in the IDE it has been due to a bad add-in. You can find out which one it is by disabling them, one by one, each time using the IDE for a while, then re-enable it and disable the next one, until the problem stops.
I still use one problematic add-in. It exhibits behavior similar to yours in that it makes the run button disappear. I avoid the problem by only loading the add-in when I need it, use it (it formats code), then I immediately unload it. If you don't use the functionality of the add-in that often, this could be an acceptable workaround.
Yea, i have this same problem with one of the add-in. But if you reset it. Shut the IDE down and open it back up again without doing anything, the IDE shouuld be able to retain the previous clean setup.
It's just guest, but:
Each graphical element on IDE (like button) is kind of resource (i.e. GDI handle).
Maybe your VB app doesn't manage these resources good enough and after sometime VB IDE cannot redraw elements like buttons (run is used often).
Also, maybe some IDE add-in is in conflict with some other add-in/application and breaks something -- I have this problem with Clip-X and MZ-Tools.
I had a similar problem when I was setting up the IDE to use for the first time, though it may not be helpful if you've been using the same IDE for a while. When I first started using the IDE, I would modify the toolbars and then close the IDE. When prompted if I wanted to save the open file I always said No, since the file was just a dummy file I was using to open the IDE with. Turns out the IDE was saving the toolbar preferences with that file, so they never got saved.
Try opening a file, customizing the UI, saving the file, then closing without modifying the code. This was the solution for me.
I've tracked down the problem and as suggested it was an add-in.
The problem went away as soon as I disabled the Visual Basic 6 Resource Editor.
How to restore your VB6 IDE without reinstalling:
Run Regedit
Find the entry for Visual Basic 6.0
Export your settings in case things
go wrong
Delete the 'UI' setting
Run VB and you will have your popup
menus back
The 'Find' button disappeared from my VB6 toolbar forcing me to select the Edit menu to use Find. I had two add-ins enabled: vbCodePrint and ResourceEditor; so I did away with both of them, turned VB6 off and back on, then put both add-ins back in and my button returned.
If you're still using the VB6 IDE, and I do amongst others, then this problem is not likely to have gone away. I use VB6 in Windows 10, and the problem is still there. But it doesn't affect me anymore.
I have had this problem a few years into using VB5 and VB6. Today, if I start VB6 directly, it may work fine the first time, but buttons will go missing the second time -- ALWAYS.
My solution, which I developed from day one:
Do whatever needs to be done to restore all your buttons. Save the Visual Basic 6.0 registry settings to a file, as suggested previously, and only keep the UI entry. Sometimes, you have to exit VB6 for it to post changes to the registry. So if this doesn't work the first time, try exiting before saving the settings.
I use my own program to launch VB6, which automatically copies my VB6 registry backup back into the registry -- by calling "RegEdit.exe /S D:\VB\IDE_Fix.reg" -- before I launch the IDE . This works every single time, and requires no action on my part.
If you read this, that means you are a programmer. You can make this work by yourself.
Mike
Reinstall,clean registry and update with SPacks etc....
Is there a good way to debug errors in the Visual Studio Designer?
In our project we have tons of UserControls and many complex forms. For the complex ones, the Designer often throws various exceptions which doesn't help much, and I was wondering if there's some nice way to figure out what has gone wrong.
The language is C#, and we're using Visual Studio 2005.
I've been able to debug some control designer issues by running a second instance of VS, then from your first VS instance do a "Debug -> Attach to Process" and pick "devenv".
The first VS instance is where you'll set your breakpoints. Use the second instance to load up the designer to cause the "designer" code to run.
See Debugging Design-Time Controls (MSDN).
It has been a pain in 2005 and still is in 2015. Breakpoints will often not hit, probably because of the assemblies being shadow copied or something by the designer(?). The best you can do is to break manually by introducing a call to Debugger.Break(). You may wrap it into a compiler conditional as so:
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
int line_to = break; // <- if a simple breakpoint here does not suffice
I have had this happen many times and it is a real pain.
Firstly I'd suggest attempting to follow the stack trace provided by the designer, though I found that often simply lists a bunch of internals stuff that isn't much use.
If that doesn't work then try compiling and determining the exception from there. You really are flying blind which is the problem. You could then try simply running the code and seeing what exception is raised when you run it, that should give you some more information.
A last-gasp approach could be to remove all the non-generated code from the form and gradually re-introduce it to determine the error.
If you're using custom controls you could manually remove the generated code related to the custom controls as well if the previous method still results in an error. You could then re-introduce this step-by-step in the same way to determine which custom control is causing the problem, then go and debug that separately.
Basically as far as I can tell there's no real way around the problem other than to slog it out a bit!
I discovered why sometimes breakpoints are not hit. In the Attach to Process dialog, "Attach to:" type has to be "Select..."'d.
Once I changed to "Managed 4.0, 4.5", breakpoints for a WinRT application were hit. Source: Designer Debugging in WinRT.
Each one is different and they can sometimes be obscure. As a first step, I would do the following:
Use source control and save often. When a designer error occurs, get a list of all changes to the affected controls that have occurred recently and test each one until you find the culprit
Be sure to check out the initialization routines of the controls involved. Very often these errors will occur because of some error or bad dependency that is called through the default constructor for a control (an error that may only manifest itself in VS)
You can run a second instance of VS and attach it to the first instance of VS (Ctrl+Alt+P). In the first instance set the breakpoints, in the second instance run the designer, and the breakpoint will fire. You can step through the code, but Edit-and-Continue will not work.
For Edit-and-Continue to work, set you control library's debug options to run a VS with the command line argument being the solution filename. Then you can simply set the breakpoints and hit F5. It will debug just like user code! As a side note, you can do this will VS and Office add-ins also.
This worked for me for Visual Studio 2022:
I opened a second Visual Studio instance
In the second instance I clicked Debug -> Attach to Process...
I selected DesignToolsServer from the process list
More details: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8