10/13/2019 Debug Settings For Unity Visual Studio Mac
Here’s how to debug an Unity3D Android application on a real device (not in Unity3D editor) over WIFI in Visual Studio. This recipe is written for Unity 2017.4 and Visual Studio 2017, maybe it works also in other versions.
Expected Behavior I built and ran a Windows build of my game; waiting on the settings window. When using 'Unity Attach Debugger' or when using 'Start Debugging' with the option 'Windows Player', we would expect the debugger to successfully attach to the Windows build. Current Behavior When using 'Unity Attach Debugger' the windows player is not suggested in the list.
When using 'Start Debugging' a dialog opens and tell us that: Could not find target name 'Windows Player'. Is it running? Open launch.json Cancel Possible Solution I am not sure but in Visual Studio 2017 Community, when I do 'Debug Attach Unity Debugger', a 'Select Unity Instance' window appears.
If I start the game before to open the 'Select Unity Instance' window, then the Windows Player does not appear in it. If I start the game after I opened the 'Select Unity Instance' window, then the Windows Player appears in it and I can start to debug. My guess is that you re-use the same implementation in VS Code, but in VS Code we can't do the trick I mentioned above (i.e. Opening the 'Select Unity Instance' window, then start the game, then come back to that window). Your Environment.
Unity Version: 2018.2.1f1 Personal. VS Code Version: 1.25.1. Version of the debugger tool: last. Operating System and version: Windows 10.
I tried it, but I don't see any new debug log information. I am thinking: it might be the antivirus.? The first time I try to run the Debugger for WindowsPlayer, Avast scans the unitydebug.exe file and wants to quarantine/block it until Avast Support team gives their green light (under 72 hours ^^). However, I went to Avast's settings and tell it to let me chose what I want to do with suspicious files. Then, when I start the Debugger for the first time, I can tell Avast: Run Anyway. It might be that Avast does not really let your plug-in run as it should?
Ok, I tried several times, and at different steps of the Windows Player start-up (1) when it open the dialog that ask to attach a managed debugger, 2) when the dialog for the setting is opened, 3) when the game's window is running). I also ran the search for the Windows Player several times, from the command palette or from the play button. VS Code consistently could never find the Windows Player. Here is the debug log: Hope that helps. How can I make sure that the firewall is not blocking the connection? For info the it is trying to set up a multicast connection on these 4 ports: 54997, 34997, 57997, 58997. These should be unblocked by the firewall.
If you run the command netstat -ano from your command prompt on windows 10 you should be able to see the process that have opened multicast connections i.e. But I must say that I am getting more and more confused by this problem. But it is very clear to me that the connection between the Windows Player and the debugger extension is not working.
There is no internal errors happening that I can easily detect. It is definitely something in the network layer which makes it much more difficult for me to fix. Whether that is due to an error between the player and your firewall, seems unlikely as you are able to see the connection in Visual Studio. Which is causing my head to be very confused. But I do also know that VSTU is injection libraries to support debug attaching in another way so maybe there is something they are doing that changes this behaviour. The same thing may be true for Rider as they start by injecting a plugin dll into your project repository to enable their extension support to work. I have made this small executable that is taking VS Code out of the equation when discovering the player connections.
I hope you can try this out. The zip contains the source code if you want to play around with this and/or build it yourself if you think you can get some debug information out of it. The executable is built under.NETFramework, the same that is used for the VS Code extension. You can find the built version under bin/Debug/GetUnityPlayerConnections.exe In addition it should show whether VS Code is blocking the connection somehow and I can get them to help me with resolving this issue. For OS X you might need to build it using.NET Core.
You could also run this using mono directly.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |