Feedback Packages and Visual Studio Projects

This has been bugging me for a little while and I finally got around to investigating it a little. Unfortunately, this doesn't look good:

The Visual Studio projects for packages are generated from the Assembly Definition files. Unfortunately, this means that those Visual Studio projects are sometimes "flattened" (e.g. Unity.Postprocessing.Runtime, which has a folder structure in the package folder, but the project is only a long list of class files), and worse:

This also means that frequently, the shaders are not included in the Visual Studio projects. And that makes searching for keywords in shaders in packages (e.g. to reduce the number of shader variants by removing paths that are not relevant to the project) a very difficult task.

I understand that originally, packages were designed primarily with "read-only" in mind - but they turn out to be a really elegant way to set up Unity projects in a much more modular way that also supports re-using "components" (= packages ;-) ).

For now, I worked around this by adding an assembly definition in the root of every package that I need the shaders of in Visual Studio, and an editor only dummy-class ... but that's kind of an annoying workaround.

What I think would be ideal is having a properly in the package manifest (package.json) that defaults to false but lets me tell Unity to create a "proper" Visual Studio project for this package. Something like createFullProject:

Code (CSharp):

1. {
2.   "name": "com.unity.example",
3.   "version": "1.2.3",
4.   "displayName": "Package Example",
5.   "description": "This is an example package",
6.   "unity": "2019.1",
7.   "createFullProject": "true"
8. }

... in this case, Unity would then create a project com.unity.example which includes all the assets (including package.json). This would also make working on packages during development much easier.

Ah, turns out Unity already does what I want for embedded packages - but embedding packages puts them under version control of the project and usually, you'll want packages version controlled separately from your project. So I guess all you need to do is treat non-embedded packages that have "createFullProject == true" like embedded packages in terms of creating the Visual Studio project for that asset.

 

Hm, actually, no. What embedded packages do is include Packages/package-folder into the Visual Studio project structure. That's not useful. Starting with the contents of package-folder and keeping the folders from there would be preferable.

 

Hi @maximeb_unity ,

thank you for following up and passing the info on. Just as a little heads up: The early implementation of Assembly Definitions caused all folders of the project to generated in the Visual Studio solutions, which created a serious problem because in large projects, this would result in Visual Studio taking several minutes to even open the solution.

So a certain level of control with different options depending on the actual needs of the projects would probably be useful.