I'm trying to run instrumentation profiler on my Unity build to know which functions are called the most and take the most time.
I have created librairies in C# which are imported in Unity, I can debug them without problems but am not able to start the visual studio profiler to instrument them.
I couldn't find an instrumentation function in Unity. Or at least it seems to crash and I get many exceptions after a few minutes of running. (ThreadDeserializer should not parse more data once it has been marked as terminated)
I have tried:
attach VS to Unity play mode but the instrumentation option isn't active
build in Unity with Debug options, PDB copied, deep profiling enabled, when trying to profile the .exe from Visual Studio I get
Unable to obtain debugging information.
PRF0002: The instrumentation with those options has failed
I also try to run my application .exe and attach VS's debugger but the instrumentation option is available.
Am I missing something?
Related
I'm quite new to VS Code. I have been debugging DLLs for 3rd party applications earlier in Visual Studio but it seems all the tools available there are not available in VS Code.
What I have been doing in VS earlier is:
create, develop and build my DLL to the plugins folder of that 3rd application (with references to the 3rd party application's libraries)
add the 3rd party exe as another project and set it as startup project.
when starting debugging session, VS automatically launches/attaches to my dll, i.e. I can step through my code when I start the plugin inside the app.
I am able to successfully build the DLL in VS Code to the correct folder and it works (will show me the simple msgbox i am waiting for). However, when I try to debug it by attaching the debugger to the 3rd party app process, the debugger does not stop at the breakpoints. When I hover over the breakpoint during debugging (which is not red anymore during debug), I get the message "No symbols loaded for this document". I guess I'm doing something wrong. The .pdb for the DLL is in that plugins directory. Is this because the debugger does not find it? Honestly, I'm not very well in with the launch.json contents yet (no need to work with those in full VS). What is the best way (if any) to do this kind of debugging in VS Code? In case this is something that definitely can't be done in VS Code, please let me know, so I know I need to return back to full IDE.
It turned out I just had some issues in my launch.json. I am now able to step through my code and the UX is practically the same than that with full VS. Problem solved.
#vernou Thanks for the link anyway!
I am currently in the dilemma of trying to attach the debugger of Visual studio to a IronPython process.
I have a c# dll that i reference and use in a python scripts, via Ironpython (import clr).
In my c# program i call this python script, again via the IronPython setup.
C# Code to run Python Scripts and its class method
Steps I have done:
So far from the research done into this subject I have figured out that you need to add the options dictionary (as seen in the code) and also disable (Just my code) in the debug options. This should allow one to set a breakpoint in the python scripts which visual studio then can hit. Now this does not work for me in both vs 2019 / vs 2022. Only vs 2017 managed to hit these breakpoints. When I run it with debugger the breakpoints simply say
(The breakpoint will not currently be hit. No symbols have been loaded for this document)
Again from the research done it looks like the fault is that vs 2019 and 2022 do not support the python version that IronPython uses and as such I am slowly giving up on. The overall goal with my project is simply to try to make the debugger work.
Question:
Is there maybe still a way to attach visual studios debugger to a IronPython process and debug the .py file??
PS: I tried both ironPython 2.7 and 3.4.1 alpha
You could add the following code in your script:
import clr
import System
System.Diagnostics.Debugger.Break()
Then run your host .NET application under Visual Studio debugger, then run the script.
The script execution should stop in Visual Studio debugger, where you will be able to step, evaluate, etc.
Also note that IronPython supports standard python tracing mechanism (i.e. settrace). With this, you could implement a custom debugger/tracer for your scripts. For example, we made such an IronPython script debugger as a part of our product called AlterNET Studio.
So I'm now using Visual Studio 2019 in C# .Net Framework.
I have been programming in Visual Basic 6.0, and when I pressed F5 the IDE run and if there were errors while debugging if I pressed the X to close the Vb6.0 IDE. a message box prompted saying if I wanted to save the changes since there were errors while debugging I pressed no.
Now in Visual Studio 2019 using C#, that doesn't happen. If I press F5 and an error occurs while debugging, it autosaves the solution with its error. How can I stop it from saving with the error in it?
No, you can't debug code that hasn't been saved with Visual Studio. If you want to see the process it goes through, do this:
Open Tools -> Options
Click "Projects and Solutions", then click "Build and Run"
Change "MSBuild project build output verbosity" to "Normal" (or, if you want to see a lot of stuff, "Detailed" or "Diagnostic"
Rebuild your project
You'll see VS invoking the compiler and passing the paths to each of your file (and to all of your references) to the compiler. It needs to save and to compile and then execute your code.
The VS debugger is a full Windows debugger. Open Windows Explorer, double-click your EXE. Now open VS, in the Debug menu, choose "Attach to process" and choose your running EXE. You are debugging it (you can attach to any process you have rights to, but attaching to a debug build where symbols are handy give you the best experience).
BASIC and pre-.NET VB started their lives as interpreted languages. A pre-processor would take your source and convert it to tokens. Then an interpreter would interpret those tokens as it ran your programs. Though the last few versions of traditional VB could compile your code to an EXE, that interpreter was still there.
In particular, the debugger used it. When you ran the VB6 (and earlier) debugger, the debugger didn't debug your program, it debugged your source - injecting itself into the interpreter, not attaching itself to the EXE. That's why the behavior you are asking about worked.
As I mentioned, getting a Source Code Control system set up (which is always a good idea) will help you get close to what you want. Git's probably the easiest to set up. Visual Studio Team Foundation Services (or whatever it is called this month) is also a possibility.
I have developed an application for hololens with Unity that uses the Hololens' depth camera. I built it with il2cpp scripting backend and it runs well on the Hololens when I launch it from Visual Studio 2017 (community). But I want to be able to debug the app (and have the output in visual studio console) while it is running on the Hololens (because I need the camera frame to be received to see how it works).
Moreover, I want to be able to set breakpoints in my .cs scripts files in my #UWP script parts.
I have been searching for a long time on Microsoft documentation and didn't find the specific answers I was looking for.
The Unity - Manual and also Microsoft - Managed Debugging with Unity IL2CPP is your friend! Check the section Debugging in the Player
In short:
In the player settings enable the capabilities PrivateNetworkClientServer, InternetClientServer
In the build settings enable Development Build, ScriptDebugging and Wait For Managed Debugger.
Build your project to a solution. Open the solution in VisualStudio.
With the HL connected run it on Device. (As debug from VisualStudio or by deploying and starting it on the device itself). Alternatively via WiFi enter the IP of the HoloLens .. just takes a bit longer to deploy of course
Wait for the pop-up.
Open any script by double click from Unity in a second VisualStudio instance (so the project's c# solution is loaded)
Here you also set the breakpoints
Go to Debug-> Attach Unity Debugger
select the HoloLens and attach the debugger
on the HL close the pop-up
You can now set breakpoints and debug c# code as usual while the HoloLens is actually running the Il2CPP solution.
I found the answer to my problem!
In order to debug c# code directly running on the Hololens, I did as follow:
In Unity :
Build Setting -> Player settings -> Other settings -> Scripting backend = .NET
Build Settings :
Build configuration Debug
check Copy reference
check Unity c# project
check development build
Then you can build
In Visual Studio 2017
Debug - x86 - Device (or remote machine)
If needed : In Solution Explorer -> For each solution -> alt+Enter -> Under Build tab check Allow unsafe code
Then you can set your break points where ever you want !
Hope this helps
Just adding a note in here, if anyone should drop by: The accepted answer is not seen as a solution going forward from 2019 as .NET backend is deprecated: See ths approach for debugging:
https://learn.microsoft.com/en-us/archive/blogs/appconsult/how-to-debug-unity-projects-with-il2cpp-backends-on-the-hololens
I am developing an application using Visual Studio, and when I install it (via Setup Project, .msi file) in a client machine and run it, I get some "Heisenbug" exception.
I am almost sure the error comes from earlier in the codepath, so I would like to debug it.
Fact is: when the application crashes, the following dialog is displayed (referring to my application instead of Windows Explorer, of course):
and if I choose "Debug the program", the Visual Studio Debugger (which is somehow available in the deployed machine) starts and shows details from the exception.
What I would like to do is to start the debugging session from the very start, so I can go on hitting F10 and F11 and check some intermediate values.
Anyone know how can I start the Visual Studio debugging session at any time while the application is running? Not that I am running the deployed application, not starting it from Visual Studio.
Since you have Visual Studio up and running on the machine running the deployed application, it should be straightforward:
Run the application
Load the project in Visual Studio
Go to DEBUG -> Attach to process...
A list will pop up with all the running processes
From the list, pick the process corresponding to the application, it should be named after your exe (if you sort by the numeric IDs, it's very likely it will be near the highest end)
Click "Attach", Visual Studio will should start debugging similarly as when you normally start with F5.
I also have another suggestion: implement heavy logging until you have everything figured out. Write down everything you have doubts about for further analysis in case something goes wrong: values, queries, etc.
You can start the application directly under the Visual Studio Debugger using the debugexe parameter:
devenv /debugexe “C:\MyApplication\Debug\MyApplication.exe”
This will launch the application with the debugger immediately attached. Otherwise it's very hard to debug issues that happen at the time the application is starting. You won't be able to manually attach in time to catch any events that happen during this time.
You can also place the following piece of code at the first line of you application (usually the Main(string[] args)) to force a debugger to attach and cause the application to break immediately:
System.Diagnostics.Debugger.Break();
If your application starts and runs fine for some time, you can use the "Attach to Program" feature as described by #Alex.
If you don't have the sources available on the target machine, you can either copy them over, or if you're using Source and Symbol Indexing features of TFS Team Build, you can tell the debugger where to look for your Debug Symbols (which will then resolve to TFS source control automatically).