Related
In visual studio 2022, when I ctr + click a method, I want to jump to the definition in new tab even if the definition is in the same file.
I can't track where I left currently since I enter several different methods while I read the code.
It's not yet possible. An extension plug-in (if it exists or one developed by you) might do the job. For now, the only thing that might help you out is using Bookmarks. Indeed, "travelling" back using Ctrl + - might be daunting, but it's the only way possible (which is why I recommend Bookmarks combined with navigation).
TLDR: Not yet possible. Maybe make an extension OR the closest you can get is if you use Bookmarks alongside navigation.
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.
In VisualStudio .net (say 2005)
I have this shortcut Alt+Ctrl+F4 which closes all the opened windows. (Already mapped to window.closealldocuments)
and another one Alt+Ctrl+Shift+F4 to close all but this window.
Now both shortcuts used to work on my previous workstation.
Both having winxp 32.And i work on sv 2005 on both.
But on this new machine, Alt+Ctrl+F4 does not seem to propagate to Visual studio, like there's some other application or the explorer mapping this key to something else, and it's not propagating the event to vs process.
I know about the 'tools -> options...keyboard' in VS, but when I press the combination in the 'press shortcut keys:' field..
it would receive these combinations: Alt+Ctrl+F5->F10 but won't receive these: Alt+Ctrl+F1->F4.
It's like you didn't press nothing.
So now... any ideas?
the problem was a process that probably was receiving the key combination and not propagating it to the rest of applications.
in my case it was hkcmd.exe (intel's graphic something ) that captures key combinations to do certain things like display rotation and such.
anyway thanks hans passant for your comment.
These mappings aren't hard coded. Not sure what happened, but it is easy to remap them. Just go to Tools -> Options then:
Click in the top indicated text box, then press the key combination, and select the appropriate command for it. I like to use Ctrl + W to close the document and Ctrl + Shift + W for all.
You can set any hotkeys manually in any version of visual studio, just go to Tools->Options...-> Keyboard and assign any command to keys sequence
I am using multiple monitors and I prefer to have my Visual Studio open in the center one and I would like the application that I am testing / running through Visual Studio open on either left or right side, rather than on top of my code.
Do you think there is a way of doing that, that is automatic ? Can this be set somewhere in the options ?
I know that one solution is to change the main monitor to the left, but that would make all apps start on the left rather than in the center.
Unfortunately not. The application is positioned by the OS and is not an option that you can set from Visual Studio.
Solution: It is simple to save the position of the application window on exit and restore it again on start-up (a MSDN blog post). Wrap it all in #if DEBUG ... #endif pre-processor so that it only occurs during development.
HTH,
Dennis
I had the same problem and eventually thought of the now-obvious solution -- make the left monitor the primary.... ;-)
I had this problem, when connected to my work place with 2 monitors through RDP from a laptop. Visual Studio opened my app in the second monitor and I could not reach it.
Win + Arrows helped me.
Sometimes while developing in Visual Studio IDE, when you use "Find in Files" dialog to find something, the search fails and you will see the following message in the "Find Results" window.
No files were found to look in. Find stopped progress
Once this message shows up, all the subsequent searches will result in the same message. Nothing fixes the problem including restarting the computer except pressing Ctrl + ScrLk.
What causes Visual Studio to get into this state and is there a setting to permanently prevent it from happening?
According to this thread:
Posted by Microsoft on 10/13/2009 at
4:33 PM
Hi all,
Thank you for your continued interest
in this bug. We have been able to
reproduce the issue intermittently in
several versions of Visual Studio
running on several versions of Windows
and have identified the root cause as
external to VS. The Windows team
unfortunately did not have time to fix
this for their current release, but we
are working with them to hopefully
have this bug fixed for a future
version of Windows. At present, the
workaround (as many of you noted) is
to press Ctrl+Scroll Lock, Ctrl+Break,
or the Break key alone.
Again, thanks for all of the details
you provided about this bug. If you
have any further questions or
comments, please feel free to post
again here; although this issue was
closed quite a while ago, I'll make
sure it stays on our radar.
Thanks, Brittany Behrens Program
Manager, VS Platform - Editor
This bug has been around since at least 2004 and, as of the above post in 2009, had not been fixed.
Sometimes Ctrl + Break works, sometimes Alt + Break, sometimes Ctrl + Scroll Lock, and other times Alt + Scroll Lock.
Right now, nothing works. This has been a huge problem for me. Shame on Microsoft for not fixing this bug in the last nine years.
Apparently, for those for who the key combinations don't work (like me at the moment), deleting the following registry key brings salvation:
MyComputer\HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\[VS VERSION NUMBER]\Find
Of course, [VS VERSION NUMBER] should be internal version number of the IDE. Don't forget to restart your computer.
Mind you, deleting stuff in the registry is dangerous. Like anyone on SO cares but anyway...
I don't think there is anything you can do to prevent it.
It seems to occur after I have stopped a build with CTRL+Break...Maybe I am pressing CTRL+Scroll Lock during that time???
I have only had it happen to me 2-3 times, and that was several months apart.
What he is saying is that occasionally when performing a search within Visual Studio you get the mentioned error message. Even though you know there is stuff to find. It is some weird state that Visual Studio gets into. If you press the (CTRL+Scroll Lock) it will 'fix' the issue.
There are currently nine bugs on the Connect site related to this and marked as Not reproducible.
I created another one for Visual Studio 2010 SP1: "Find was stopped in progress" while performing search in Visual Studio
Please vote for it if you are unable to perform search.
PS: Microsoft claims that they fixed it in Visual Studio 2012.
I have had this problem and saw peoples' answers about the multiple Ctrl + Break/Pause Scroll Lock combinations.
I considered this, but I thought it a poor workaround (especially as I use a Mac Keyboard so those keys are not easily available).
So the solution I found was to do this:
Menu: Tools → Options → Environment → Find and Replace
Uncheck the top three check boxes (checked by default in my settings).
Re-check the top three check boxes.
Et voila, everything should work fine.
Well, it did for me anyway, which was a relief as I can't believe Microsoft would allow a weird key combination as a work around for a bug like this.
I submit this hoping it may help!
See if this Stack Overflow question helps:
Search stops working for "Entire Solution"
Short version of the solution:
You should try clicking inside the Find Results window, and once the blinking text cursor is visible, hit Ctrl + Break four or five times. That should do the trick.
My experience with this problem:
Steps to Reproduce
I just experienced this using Windows Server 2008 R2 Standard and Visual Studio 2010 SP1.
I was accessing Visual Studio remotely through Citrix Receiver (from my computer, A, to B) and through Windows Remote Desktop (from B to C). In this set-up (chaining two remote sessions), I sometimes have stuck modifier keys.
In B, I had pressed Windows+Pause to access the System Properties window. (This may or may not be related; I suspect there could have been a stuck key press or something.)
Later on, when I opened Visual Studio on C, I had this problem. Note that I always use Ctrl+Shift+F to access the Find All window.
Solution
I solved it by pressing Ctrl+Scroll Lock as suggested in other answers.
Cause
As for why this happens, I did notice that if I press Ctrl+Break while the text cursor is in the Find Results window but before any results are found then the search stops with the same message. This indicates to me that it's related to a keyboard problem.
As reported by others, apparently it's a Windows bug. Here's a discussion about this.
I encountered a very similar problem. I was searching a folder for all files for a phrase in all .cs files in my solution. Visual Studio kept saying "No files were found to look in". (It did not have the "Find stopped progress" part of the message.)
I searched for the message and found this question. The suggested keyboard commands in other answers did not work.
I like to use the keyboard for navigation. I had accidentally hit Alt+B and Space. Alt+B is the shortcut to jump to the "Include sub-folders" checkbox on the Find and Replace form. The space bar cleared the checkbox, and then Alt+A performed a Find All action. Because it was not searching sub-folders, no files were found. The message was correct.
After checking the "Include sub-folders" box, searches found the matching files in sub-folders. So if you're getting the message "No files were found to look in" without the message "Find stopped progress", ensure the search is looking in sub-folders!
I thought I was seeing this problem, but after two days of searching for a solution I figured out that the "Look at these file types" selector had changed and didn't include the file extension I needed.
I had this in Visual Studio 2015 yesterday.
In Find in Files, in the textfield Look in:, I typed
*.*
instead of Entire Solution, and that also caused No files were found to look in.
This is not a Visual Studio bug or Windows bug. It's a keyboard bug. Please see an answer in duplicate question https://stackoverflow.com/a/28219093/147805.
I can reproduce your issue.
There are some steps as following below you can try:
Check the setting Find and Replace (menu Tools → Environment → Find and Replace).
Open "Developer Command Prompt for VS2013" and paste
“devenv.exe /resetsettings”
Use the Visual Studio Setup Wizard (via Control Panel) to repair Visual Studio. You also can read the reference about Find in Files:
http://msdn.microsoft.com/en-us/library/dechx2tz.aspx
I have found another cause of this: Moving the solution folder to a new location, when CMake is part of the build process.
I was working with the Chromium Embedded Framework and moved the main CEF folder from e:\ to c:\ . This seems to break everything including Find because the CMake build scripts it uses hard-code the disk volume and full path (E:\folder) into the source paths.
To be clear, Press Ctrl + ScrlLck, with the Search Window open. That resolved it for me too.