I’ve been experimenting with the Package Manager, specifically with the PostProcessing package.
Previously, my generated Visual Studio projects contained source code for PostProcessing (since it was in my Assets folder). This allowed me to use the Visual Studio text search tools to find code in PostProcessing another packages I’d installed in my Assets folder.
However, using PostProcessing from Package Manager, I noticed that Visual Studio text search tools no longer work. It appears that Unity Package Manager packages do not appear in the Visual Studio project at all anymore.
Is there anyway to include the packages in my project like before? If not, is there another project that I can open to at least search each package individually?
At that point, if I do a Find All on “PostProcessVolume” it will appear in the search results. However, other post processing file results do not appear, only the ones I’ve done an F12 lookup on.
Previously VSTU was in charge of generating project files and solution file. Starting with 2018.1, VSTU is now using Unity’s generated files. So probably the different generation logic introduced this behavior.
Could you try to provide a working project (like when using an older Unity version < 2018.1), and your current project so that @lukaszunity will be able to diff generated files and find the potential issue ?
Hi Sebastien. The difference isn’t between older versions of Unity and newer versions of Unity. The difference is between using the new package system and not using the new package system.
Previously, you brought packages into your Assets folder, which meant they were included in the Visual Studio project.
Now with the Package Manager, when you import a package it’s source files are no longer included directly in the Visual Studio project (so the Find in Files tool doesn’t work for files in the package).
I don’t think this is a Visual Studio bug, I think it’s just due to how the Package Manager works.
The reason I started this thread is because, while I like the new Package Manager, it does make understanding your games code base more difficult since it’s harder to search all files in your game from a single place.
While trying to understand the lightweight render pipeline I encountered this same problem; Visual Studio doesn’t know where definitions are because the packages aren’t in the same solution.
My work-around was to clone the scriptable render pipeline code from github (though I suppose you could also grab the packages from the cache) and add it to a Packages subfolder under assets. This can result in conflicts with the version compiled via package manager, which I haven’t figured out how to solve yet, so the work-around only really works in clean Unity projects. You might then still run into issues with shader includes, so you might have to change those to relative paths.
Once I worked through all those error messages, I managed to get the lightweight scriptable pipeline working this way. Maybe you can do the same for the post processing package.
That said, it seems to me that Unity should add the packages to the same solution file, so that Visual Studio’s functionality just works. (Before trying this work around, I made sure that I was using the latest Unity plugin for Visual Studio 2017, using Microsoft’s updater.)
How do I find out what the latest is?
Visual Studio tells me: “Visual Studio 2017 Tools for Unity”, version 3.9.0.3
Unity Package Manager tells me: “Visual Studio Editor”, version 1.0.11
Unity version is 2019.3.0b1, but I’ve seen this since package manager got introduced
The behaviours I’m seeing:
Visual Studio opens many many instances - sometimes after double clicking on a newly created script, sometimes if some scripts were already open in VS (from the same project but inside different asmdef)
in some projects I’m getting csproj files for Packages in some not (on the same Unity version), this seems to depend on whether the project was updated or newly created (works better in newly created ones)
in some projects I had to manually delete sln+csproj files that existed before new ones were generated for different packages (in one case I had a sln file that Unity created back in 4.7, in a project that I continuously updated, and that sln file seemed to have prevented generation of package csproj files)
I can’t navigate code inside of packages when opening them in visual studio, also I can see that there is no csproj for them
the magical button “open C# project” only creates csproj files for things in Assets and for packages that are editable, but not for regular packages
It says “Added support for Unity packages in the UPE. Only Referenced packages (using manifest.json in the Packages folder) and Local packages (embedded in the Packages folder) are visible.” Version 4.1.0.0, released May 21, 2019.
However, the latest available version according to the Extensions marketplace is 3.9.0.3. Visual Studio 2017 has all the latest updates, the machine has all the latest Windows updates. Are you seeing a different version?
Yes, I’m serious. I don’t use VSTU. I’m sorry I cannot be of help here. This is the community forum, so maybe a user or one the VS plugin authors/maintainers can respond (One of them is on this thread). You can also fill a bug to Microsoft.
Having the same problem here… Trying to look deep into ‘Addressables’ and Visual Studio bugs me. Or maybe Unity PackageManager can import those Packages into ‘Assets’ folder as an option?
For something constructive: how do you solve this need to navigate code, @okcompute_unity ? if you had to find the references of a script that resides in a package, to understand how the package works, or maybe to find where a particular value is assigned, do you have a way of navigating package code in your preferred IDE? or do you do it the 80’s notepad way and keep everything in your head?
I discovered that Rider has the ability to do what the OP was looking for, but that’s not visual studio as I first thought…
anyway that also costs money so I was hoping to find a free solution
Hi, I found that enabling “Preferences>External Tools>Generate all .csproj files.” then “Assets>Open C# Project” makes VS code navigation works for all of packages. I tested with Unity 2020.1.b2. I hope that this workaround help you.
Note that if you use Assembly Definitions, you’ll need to have a top-level definition that includes references to the package assemblies you’re using in order for this to work (but you should have that anyway).
If you don’t have any knowledge of the problem, probably best not to comment with your Unity account. It looks especially terrible when people come along later and find this mocking “sucks to be you” type of comment. Fortunately someone from the community found the solution despite you throwing in random red herrings about VSTU version numbers. And fortunately, as this is a community-driven forum, me criticizing a Unity employee’s behaviour is perfectly acceptable.
I wanted to be honest and let the community help this fellow. VSTU is not developed by Unity. This is a software developed by a third party. I don’t use Visual Studio. I use a mix of Rider and Vim.
Yes, I’m working at Unity. Yes, I have to be careful at what I’m saying. In this situation, if you understood “sucks to be you” from me, then I don’t know what to say. I read what I wrote again and this is not what I’m understanding from the words I wrote. Maybe this is because English is not my native tongue?! Anyway, sorry if you felt that I was mocking you. I’ll be more careful in the future.
Awesome, thanks ^^