Developing a Package within a project - workflow broken in 2019.4?

I found the solution - see first reply below.
------

First, my setup. I have two things I’m developing at the same time:

  • My custom Package that is meant to be reused across multiple Unity projects
  • A Unity project that depends on the Package

So you could say I am building the game and the Package in parallel. My Package code is in its own repository, and each project is in its own separate repository.

In 2019.3.1, this worked really well. When I tell Unity to open the C# project in Visual Studio, I have access to not just the project code in the usual Assembly-CSharp project, but a MyPackage project is also in the Solution Explorer, corresponding to the asmdef I placed in the Package folder. Within a single Visual Studio instance I have access to code from both repositories in a single VS solution, and there are no issues with intellisense or anything like that.

However if I upgrade the project to 2019.4.0, then the MyPackage project is no longer available in my VS solution. Instead, it seems Unity is now compiling my Package code separately and only making it available as a library reference to Library/ScriptAssemblies/MyPackage.dll. I can reference the Package code inside the DLL from my project code, but I can’t work on those scripts inside VS. I can double-click a Package script in Unity to open in VS, but things like Intellisense are broken because the “loose” C# file I’ve just opened isn’t considered part of the open VS Solution.

This is really frustrating because it’s important to be able to work on a package within the context of it being used in a Unity game project. I’d like to edit my Package code and immediately see if my changes will work in the project, without needing to have multiple Unity windows or multiple VS windows open at the same time.

What do the folks at Unity envision as the “intended” workflow for development teams like mine? Should the Package folder (i.e. the folder containing the package.json file) be inside the Assets folder of another, separate Unity project that I use for “testing”? Or am I supposed to import the Package folder to Assets of my project that I’m working on instead of adding it via the Package Manager? Because ideally we would maintain a logical separation between the two things. Partitioning off the Package stuff under “Packages” in the Project window of the editor enforces a separation of concerns and also reduces project clutter. We don’t want the Package contents to be duplicated into each project’s separate repositories because that’s a mess and isn’t maintainable. That’s roughly what we were doing for years before the Package Manager was introduced and reached maturity last year, and in 2019.3 as I described above, everything feels perfect. But then that went away.

So I ask again… what’s the idea here?

OMG… I have already found the solution! I spent hours last night trying to figure out what was going on and eventually decided to post this thread and now less than an hour later I discovered what’s up on my own… that’s how it usually goes…

  • Edit → Preferences

  • External Tools

  • Create .csproj files for:

  • Embedded Packages [×] <<<----- check whichever of these is relevant to you

  • Local Packages [ ]

  • *

  • etc

This new set of checkboxes in Preferences is new as of somewhere between 2019.3.1 and 2019.4.0… I don’t know where this is mentioned in release notes, but I strongly think this set of options in Preferences should be mentioned somewhere in the Package Manager documentation!!! That would have saved me so much headache.

2 Likes

Oh my god thank you I was in this exact same situation and had the same problem, you saved my day !