I think most of us are used to have the debugger “Step into” methods in a DLL (given we have all its symbols imported and the DLL’s project available on disk at the right location)
I hope someone will address this soon with packages, because as of 2019.2.20 I’m not able to debug a package’s scripts, even for embedded packages, which are supposed to be “in-development” packages.
I think any kind of package should be debuggable if the source code is provided, regardless of whether it’s embedded, local, git-based etc.
I’m surprised you cannot do this in 19.2. This is an IDE dependent feature though. Have you look into the External Tools forum to see if others are having the same issue? In theory, we give the IDE publishers everything they need to enable debugging package sources.
I can’t debug packages either using Visual Studio. Also, when I “F12” (“Go To Definition”) on a method defined in a Package, it takes me to the automatically generated view of the dll file. I have tried these things and it still doesn’t work:
-Reimport all
-Delete .sln file and reimport
-Checked “Generate all .csproj files” in Unity prefences
I have the following installed:
Visual Studio Tools for Unity version 4.5.1.0
Visual Studio 2019 Version 16.5.4
Unity 2019.3.7f1
Any ideas, as I’d really like to debug some packages!
Interesting I just discovered that if I place a break point in a package file, it will break whilst debugging so this is a good short term solution. However it is still strange that I can’t step into functions, can’t F12 on things and also don’t get the hover information that can be added in the
@okcompute_unity
Although @hugeandy has a solution for the local, “in-development”, packages, I still would like to be able to step into a package’s source code even for git-hosted repos, or actually any kind of repos. Since I have the source code, I should be able to step into them.
Currently, I’m using a common code-base for both the server and the Unity client, and it’s deployed as a UPM package.
I’m constantly forced to switch between the local path for the package (to debug it while in dev) and the github path of the package (to be able to push the client code to Unity Cloud Build and run it successfully).
You can see that being able to debug a package that’s hosted remotely would speed up the development significantly, since I won’t need to switch back and forth between a locally-referenced package and a remotely-referenced package - I’ll only use the latter.
It’s been some time since I could resume the work.
Maybe I’ll look into Rider as it has more features. The reason I use VS is because it’s faster by all measurements, even on top-notch workstations.
Until then, I discovered I needed to check the ‘Generate project files’ for the git packages in Preferences, then press Regenerate projects. This allows me to debug which is wonderful (instead of needing to manually modify the manifest.json to point to my local dev package).
However, there’s a major problem with this: it allows you to modify the project’s files without warning you about the changes. I was expecting Unity would have a ‘watcher’ daemon of some kind that notifies us that a package under /Library/PackageCache became dirty. Wouldn’t that be an essential functionality, in general, even outside of our current scope? Otherwise, anything can modify a package and these things are impossible to diagnose because you don’t see any changes in git.
Is anyone else having trouble debugging into packages like me lately? I’m using Unity 2022.2.6 with Visual Studio 2022. I can explore the packages (their projects are added to the solution), but I cannot break into them. Any added breakpoint will have that empty circle look to indicate that it cannot hit (and if I run the game, it indeed doesn’t hit).
Hello, I have been working lately a lot with custom packages (as git submodules) and just discovered a similar issue to yours. I have some custom packages (let’s say pack1 and pack2) used in 2 project proj1 and proj2. What is intersseting is that the generated DLL and PDB for in Librayr folder of Proj2 for some package (let’se say pack1) hare actualle referencing source file of pack1 in proj1 !!! (just opening dll in a text editor and search for proj1 or proj2). And this is why I cannot add breakpoint in Pack1 source file from Proj2. I have been struggling on this issue for 2 days now…
Seems it is related to the global package manager cache for “MyAssets” that apparently somehwo keeps a reference for each custom package to the first project that generated the DLL (I have no clue how). I just submited an incident in UNITY. Workaound: when i want to debug a project referencing some of my custom packages I first delete everything under "//AppData/Roaming/Unity , then close all unity projects, remove the dir “Library” in desired project and then open it in UNITY.
Maybe it’s me who is doing things incorrectly.
I also just ran into this problem. Things were going ok for a while. VS kept whining about not being able to hit breakpoints, but most times re-attaching fixed things.
This time it didn’t. I tried using Rider. It broke into the same function the first time, then stopped with message “Cannot find associated modules for this…”. Function is in an embedded package’s code. VS again, it breaks into scripts under Assets, but not the package. I’ve tried what Jojo says, minus the AppData part, before, but nada. It also kept saying it couldn’t find the appropriate location for the breakpoint. Weird thing is that Module window in VS shows the dlls are loaded, including their pdbs.
UPDATE: Tried deleting the AppData caches too but still no dice.
Still happens for me, but I’ve narrowed it down to embedded packages. If I move the package out of the project and re-add it as a local package, I can break into it.
Final update. Turns out somehow an entry for the embedded package ended up in the manifest. I don’t remember adding it there, but it was what created the conflict. I’m guessing Unity tried to both treat it as an embedded package and a local one (manifest entry), otherwise it doesn’t make sense.
That said, I still have issues with attaching every now and then. Certainly when you attach without project being in debug mode, it ends up in an endless loop sort of, where VS throws a popup allowing you to force stop the attachment.
