Allow option to build solution and csproj files in a subfolder

So I’ve fully embraced the use of Assembly Definitions in Unity, and really like how it imposes clean design on your scripts. Sure it can be painful to get third party assets to play along, but so far so good.

The only problem is that many of my projects end up having 25 or more assemblies and thus csproj files. This ends up polluting the root Unity project folder, filling it up with files that on a day-to-day basis i have no interest in, compared to important files and folders that store actual project information, but for various reasons shouldn’t be stored in Assets.

As far as I can tell there is no good or simple way to relocate these files as Unity will regenerate some or all of them whenever you make a script change.

So I was wondering is there any reason why Unity couldn’t just build these files in a sub-folder of the Unity Project instead of dumping them as loose files? Maybe its a restriction with VisualStudio or something, but if not then i’d love to see a preference option to build to an Unity designated subfolder ( e.g. ‘Solution’ ). Being able to specify the subfolder name would be nice, but not essential.

3 Likes

Did you solve this? I would very much like this too.

1 Like

Sadly not. Was hoping Unity might provide the option to do this, but unless its been added to recent releases I don’t think they have.

can we start a feature request ticket somewhere?

Why are you even looking in the root folder? All the csproj, sln and userprefs files should be in your source control ignore file so you never even see them.

Yes I suppose that it can grow up to a lot of files when working with a lot of assemblies, but they’re tiny in the grand scheme of things, especially compared to the massive number and size of files in Library/, which are also intended to be ignored by source control.

In short, don’t hold your breath for this to be “fixed.” I’ve never seen even one person consider this a problem, as source control properly configured always ignores all of that Visual Studio noise.

1 Like

I think you’ve got the wrong end of the stick here, this has nothing to do with ‘number of files’ in a project or access to these files, its about visual clutter of the root folder, nothing to do with source control or anything that source control solves.

When I wrote my original post I mentioned 25+ csproj files, within two years thats grown to over 50 now and I expect it to grow further as I move more code over to packages and embrace newer features of Unity.

Cluttering up the root folder needlessly causes me grief with the type of projects I develop for the type of clients I have. I could literally write pages of details as to why its useful and indeed sometimes necessary for me to store files and content in the root folder, but it would be a time waste, just accept the fact that other developers use Unity in a different manor to yourself, often forced to due to using third party tech or other reasons and sometimes just the stupidity of clients that i’ve gained with 30 years working in the field.

But how about this, since source control fixes this problem and filling up the root folder with files doesn’t matter, why not just store everything in there? Why bother having a library folder, or the .vs folder - lets just have a single folder per project. - You don’t, that would be stupid, because it creates visual clutter and pollutes the space jumbling up files together.

Correction you’ve seen at least two in this thread :wink:

OH! I see… so your project looks like:

MyGame/ProjectSettings
MyGame/all-clutter-goes-here.csproj
MyGame/important_project_documents.txt
MyGame/even-more-visual-studio-clutter.sln```

Without exception, every game I make, every game our company makes, and even gamejam games, 100% of them, we always use a subfolder for the Unity project, usually named the same. The above becomes:

```MyGame/MyGame/Assets
MyGame/MyGame/ProjectSettings
MyGame/MyGame/all-clutter-goes-here.csproj
MyGame/MyGame/even-more-visual-studio-clutter.sln
MyGame/important_project_documents.txt```

I would never even go looking in ```MyGame/MyGame```, only the root folder "above" the Unity project.

I recommend this way of operating to every Unity user.

It's also great if you decide to make another Unity project within the same repository: you just make a folder such as ```MyGame/MyExperiments``` and go nuts, put another Unity project in there, or more docs or whatever.

Note quite, but close and I already often have a parent folder or two, but that again is not the reason for placing other data in the root folder. You see you are still coming at this from a ‘rational’ pov and not how I have to due to working with clients.

The problem you are missing is the final build and the location of important settings files and runtime content and how end clients expect to be able to interact with that data, whether they should or not - and believe me after 30 years I’ve had clients waste far too much of my time by moving stuff or constantly having to explain to them where to update files again and again and again.

So what has proven most successful for both

  • allowing clients to update content without bugging me every 5 minutes.
  • preventing other clients from ‘trying to be helpful’ and moving half the built project files somewhere.

Is to store certain content in the project root folder. Anywhere else just eventually ends up with support calls.

However there is also just the ‘visual clutter’ aspect, that is a pet peeve of mine. I hate it when I have to scroll in a explorer window, especially if simply having better folder organisation could resolve it. I hate seeing all those files and not knowing if something important is at the bottom so you have to scroll just to check. I mean isn’t it weird how everything but csproj files in a unity project folder is self contained within its own sub-folder?

I do agree though regardless of the csproj issue its perhaps time I tried to find a better solution to my 'dumb ’ ( but lovable ) clients issue and store all data in a subfolder, but its likely to risky for existing legacy projects. I’ll never get over the ‘visual clutter’ issue though.

Saying that i’ve been looking at the VS Code Editor package in Unity and can see where it writes the sln file pointing to the csproj files, so assuming VisualStudio supports having csproj files in a subfolder ( for Unity ) I could easily add that. However as of yet, i’ve not found where Unity writes the csproj files themselves, to busy answering forums questions :wink:

Are you using source control? It sounds like not, otherwise you would ignore those files everywhere they might be and the client couldn’t do anything with them even if they found them on their systems.

Its nothing to do with source but builds! That’s the whole point. In order for the clients to easily access user settings and also not to move the build or parts of the build around and brake it, the settings and content need to be in the project root. Its not purely just clients though its also for ease of access for myself and other users in the company. If I want to change an ini setting I want as few clicks as possible and again the project root is the shortest root.

Note:
The following is simply proof-of-concept stuff. It only applies to Unity 2019.4.28 and com.unity.ide.visualstudio (2.0.16), though as changes are being made to a single file it should be possible to extrapolate to newer versions.

I made some progress with a custom version of com.unity.ide.visualstudio package. I embedded the package in the package folder and made two changes to ProjectGeneration.cs. These changes placed all the VS files ( including .vs and obj folders) into a subfolder called ‘solution’ - though i’m lazy and the code doesn’t create that folder, you have to do it yourself at the moment.

Unfortunately while this appears to work with a test project and all files can be accessed via the ‘Solution Explorer’ in VS, it fails to generate/populate the ‘Unity Project Explorer’ section. Not sure why that is, and I don’t think the VS Unity plugin code is open source so hard to check.

If I were to guess its looking for the solution file in the project root or worse it expects all the solution files to be in project root which means back to square one. This is the main reason why I hoped that Unity might implement this feature to choose where to create the solution files as they will understand the situation better than anyone else. For all I know what I want to achieve is impossible and a Unity Tech familiar with this stuff would know and could just say.

Edit
I made a few more changes so that the project sln file stayed in root folder while the csproj files were placed in a subfolder called ‘VSProjectFiles’ ( again I haven’t bothered to create the folder, you have to do it by hand ). This is quite nice and tidy and again works fine (for the few limited tests I did) with the ‘Solution Explorer’, auto-complete etc, but still nothing in ‘Unity Project Explorer’. Ultimately I guess this might not matter too much since everything else appears to work, its just nice to be able to browse the project as its presented in Unity browser.

So not sure what is required for VS to populate the ‘Unity Project Explorer’ and not sure its possible to find out. Not that this is a great solution to the problem anyway since it means you have to use a customised version of Unity’s visualStudio.package and embed it in every project.

Oh just discovered that Unity has an AssetPostprocessor for SLN and CSProject generation. The VisualStudio Unity Docs were useful to discover this. While not very practical as it simply passes you the generated file, it could be used to modify the file, but sadly the filepath is fixed so ultimately has no use for this purpose. You can’t even move the file as it doesn’t exist at this point in the processes and i’m not sure if there is a relevant hook later but before Unity opens visualstudio.

8504300–1132649–ProjectGeneration.7z (8.58 KB)
8504300–1132667–ProjectGeneration_VSProjectFiles.7z (8.62 KB)

2 Likes

All I want is just not to open the door and see toys all over the rootPath. they should be in a box. and I don’t wanna see them before I open the door neither.

1 Like

It appears maybe you didn’t read my post above?

https://discussions.unity.com/t/800684/7

Another downside of placing .csproj files in the root of a Unity project is it creates unnecessary nesting of folders in Visual Studio’s Solution Explorer.

For example, I have the following folder structure:
ProjectRoot → Assets → Source → InventorySystem → InventorySystem.asmdef

Instead of the .csproj being autogenerated next to the .asmdef file, it’s placed in ProjectRoot. In Visual Studio, the Solution Explorer will show "Assets → Source → InventorySystem " folder structure when the project is unrolled. It’s unnecessary to show Assets/Source/InventorySystem, you’d only want to see folders that live in the InventorySystem folder.

In most project setups, source files live at the same level or underneath the .csproj file. If Unity autogenerated the .csproj files next to the .asmdef files, it would clear up clutter all over the place. I’d love to see this fixed.

3 Likes

Post is getting old. Please create a new thread if you wish to continue the conversation.