Where to Install Your Assets (for Scripting Packages/Editor Extensions)

[SonicBloomEric]

Where Should My Extension Be Installed?

This is a natural question for developers interested in submitting an Editor Extension/Scripting Package to the Unity Asset Store.

A detailed writeup about this follows, but for those looking for the quick solution (the TL;DR version), this depends on the version of Unity you’re using.

Unity 5.2.2+
Unity quietly made a change in Unity 5.2.2 to support Editor folders anywhere in the Plugins directory (read: not directly underneath Plugins). If you plan to support only Unity 5.2.2 and above, Editor Extensions/Scripting Packages should be installed as follows:

Main Contents: Assets/Plugins/[Package_Name]/...
Editor Scripts: Assets/Plugins/[Package_Name]/**Editor**/...
Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

Legacy Unity
If you need to support Unity versions prior to Unity 5.2.2, Editor Extensions/Scripting Packages should be installed as follows:

Main Contents: Assets/Plugins/[Package_Name]/...
Editor Scripts: Assets/Plugins/**Editor**/[Package_Name]/...
Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

Onward to details!

The [Wrong] Default Approach

Most extensions appear to install directly into a project’s Assets folder root, which feels like a natural solution:

Main Contents: Assets/[Package_Name]/...
Editor Scripts: Assets/[Package_Name]/Editor/...
Editor Resources: Assets/[Package_Name]/Resources/...

It turns out that this actually has two pretty surprising problems:

• If the package has scripts and supports an API, only the original language the API was written in can be used to interface with it. This has to do with the Script Compilation Order.
• All assets in the Resources folder are actually included with your user’s build, even if they’re GUISkins or fonts intended solely for use with your EditorWindow!

Unity provides mechanisms for getting around these issues: the Special Folders. There are three different Special Folder groups that circumvent problem 1 above:

• Assets/Standard Assets/...
• Assets/Pro Standard Assets/...
• Assets/Plugins/...

The [Pro ]Standard Assets folders appear to be used for the standard assets that Unity provides with every installation. This leaves the Plugins folder which doesn’t look like a great location for non-native (or, at the very least, assembly) plugin installation, given the documentation.

So which is better? Unity engineers have informed me that

“[The Plugins folder] does not necessarily signify native plugins.”

Nice. This means that if you wrote your Editor Extension in C# and wanted someone writing in Unityscript or Boo to be able to interface with your tech out of the box, you will need to organize your package for installation as follows:

Main Contents: Assets/Plugins/[Package_Name]/...
Editor Scripts (5.2.2+): Assets/Plugins/[Package_Name]/Editor/...
Editor Scripts (pre-5.2.2): Assets/Plugins/Editor/[Package_Name]/...

A Source of Confusion/Common Misconception(?)

It has become apparent that there is a lot of confusion about Special Folders and how they work, even for Unity employees. It appears as though most people believe that they follow the generic Editor folder rules:

• Scripts inside a folder called Editor found almost* anywhere will be compiled in a separate pass from game scripts.

• Scripts in these folders are not included in Assemblies for final builds.

• this will be addressed below, but Editor works differently when combined with other Special Folder names in versions of Unity prior to 5.2.2.

By this I mean that most people seem to expect that the following would work:

• Scripts inside a folder called Plugins are compiled in the firstpass compilation pass, and therefore accessible by any scripting language.

By this logic, the following folder setup should enable a library written in C# to be accessed by scripts written in Unityscript or Boo:

Main Contents: Assets/[Package_Name]/Plugins/...
Editor Scripts: Assets/[Package_Name]/Editor/...

This is NOT the case! According to current Unity folder rules, this results in all package scripts getting compiled in the normal pass. Further, the Editor scripts end up in the normal Editor compilation pass, not the firstpass one.

Okay, so Plugins isn’t a magic “anywhere folder” like Editor. Fine. Let’s try to move our package into Plugins, then, to get that language agnosticism. Results here depend on what version of Unity you’re targeting.

For Unity 5.2.2+

This works in Unity 5.2.2+:

Main Contents: Assets/Plugins/[Package_Name]/...
Editor Scripts: Assets/Plugins/[Package_Name]/Editor/...

Great. Skip ahead to the What About Resources? section below if you don’t care about versions prior to Unity 5.2.2.

For Pre Unity 5.2.2

Unlike recent versions of Unity, this doesn’t work for versions prior to 5.2.2:

Main Contents: Assets/Plugins/[Package_Name]/...
Editor Scripts: Assets/Plugins/[Package_Name]/Editor/...

The problem is that all scripts now end up in the firstpass assembly for game content - the Editor scripts do not end up in the Editor-firstpass assembly as we’d hoped! In fact, they do not end up in an Editor package at all, resulting in errors (no UnityEditor) during the build process. This is because when placed within Special Folders, the Editor folder name does not follow the standard rules! As outlined in the pre 5.2.2 documentation, you must place your Editor scripts in the Assets/Plugins/Editor folder to gain Editor-firstpass compilation! Therefore:

Main Contents: Assets/Plugins/[Package_Name]/...
Editor Scripts: Assets/Plugins/Editor/[Package_Name]/...

In summation, the Plugins folder does not work like standard Editor folders. And, for that matter, Editor folders under Assets/Plugins do not work like Editor either.

What About Resources?

In case you weren’t already aware, everything in a Resources folder ends up in a special package called resources.assets that is included with the build package. This means that if your nifty Unity library includes nice Editor UI icons in a folder called Resources, those will end up in the final game! That’s just wasted space for your user (or yourself)!

Luckily Unity provides a special option for assets that are intended for use solely within the Editor. Such assets should be placed in a special folder called Editor Default Resources:

Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

Assets (textures, skins, fonts, etc.) in this folder will not end up in the exported resources.assets package at build time. Note that these are accessed using a special API call: EditorGUIUtility.Load.

So this implies that if you wish to play nicely with the Unity Special Folders and gain access to their advantages, a full Editor extension would need to be installed with the following setup:

Main Contents: Assets/Plugins/[Package_Name]/...
Editor Scripts (5.2.2+): Assets/Plugins/[Package_Name]/Editor/...
Editor Scripts (Pre-5.2.2): Assets/Plugins/Editor/[Package_Name]/...
Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

Why This Is Important; Going Forward

As Editor Extension developers the goal is frequently to create a library that provides some enhanced or added functionality to the user. In an ideal word, the solution provided should enable the end user to integrate your extension with their workflow with minimal effort. This means supporting all Unity-supported scripting languages. At present, this is possible but only using the folder structure outlined above.

Some of the Unity engineers I’ve talked to seemed to be under the impression that all of the special folder names acted the same way as the Editor name, implying that the following would work:

Main Contents: Assets/[Package_Name]/Plugins/...
Editor Scripts: Assets/[Package_Name]/Plugins/Editor/...
Editor Resources: Assets/[Package_Name]/Editor Default Resources/...

The benefit to such a setup is that everything would be contained within a single folder that the end-user could reorganize as they saw fit while maintaining the benefits of firstpass compilation and Resource usage. When they realized that such a setup did not work according to their expectations, they considered it a bug and something that should get fixed. Nice.

Hopefully, barring a full package system overhaul, something like the above will become viable in the near future, representing a relatively simple solution for both extension developer and user!

[Prodigga]

@SonicBloomEric

Some of the Unity engineers I’ve talked to seemed to be under the impression that all of the special folder names acted the same way as the Editor name, implying that the following would work:

Main Contents: Assets/[Package_Name]/Plugins/...
Editor Scripts: Assets/[Package_Name]/Plugins/Editor/...
Editor Resources: Assets/[Package_Name]/Editor Default Resources/...
The benefit to such a setup is that everything would be contained within a single folder that the end-user could reorganize as they saw fit while maintaining the benefits of firstpass compilation and Resource usage. When they realized that such a setup did not work according to their expectations, they considered it a bug and something that should get fixed. Nice.

Sorry to bump such an old topic!

Until recently I was under the impression that this worked just fine.

We have a large framework of code that we have developed in house. The framework has lots of different ‘modules’ that we separate into their own folders. For example, if a module has some plugin data (jar files, etc), it goes here:

Assets/FrameworkCode/[Module Name]/Plugins

So, we have lots of different plugin folders:

Assets/FrameworkCode/NativeLocalNotifications/Plugins
Assets/FrameworkCode/NativeReviewPromptDialogue/Plugins

This actually works just fine for android and iOS library files (.jar and .a). When we build for iOS, it finds all the .a files correctly, and for android it finds all the jar’s correctly! But this is all that works. Two big issues!

• Scripts (.cs) must be in Assets/Plugins to be compiled as part of the ‘plugins assembly’.
• It seems like any manifest file outside of Assets/Plugins is completely ignored (Permissions are not merged, receivers are not merged, etc), so this means that you are limited to a single ‘AndroidManifest.xml’ file and the ‘xml merging feature’ of Unity, (I am pretty sure I read that there was one?) is useless.

If we could get the Plugins folder to work like the Editor folders, that would make organisation so much easier. Right now, we can place an editor folder anywhere and it just works fine. We should be able to place a Plugins folder anywhere as well, and have its sub folders register correctly( Plugins/iOS, Plugins/Android, etc).

[SonicBloomEric]

@Prodigga

Sorry to bump such an old topic!

Old but still relevant! (Unfortunately…)

@Prodigga

If we could get the Plugins folder to work like the Editor folders, that would make organisation so much easier. Right now, we can place an editor folder anywhere and it just works fine. We should be able to place a Plugins folder anywhere as well, and have its sub folders register correctly( Plugins/iOS, Plugins/Android, etc).

The “Editor folder anywhere!” feature came in fairly recently (5.2.2). I suggested something similar to a Unity Developer in the form of “Folder Properties” (with a fallback suggestion of at least adding unique icons for Special Folders). Effectively I was told:

That is something we are considering but it is nontrivial to do. … We are probably going to do the folder properties thing (after 5.4 launch sometime).

We can only hope that the timeline for “after 5.4 launch” is on the shorter side…

[SonicBloomEric]

A user ( @zwcloud ) posted the following question to this post on the “new” forums during the brief period they were up:

@""

OK, so it is the user who is responsible to put editor-only resources in the directory:

@SonicBloomEric

Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

Because we can only select one single directory as the asset directory in the Asset store tools when upload the draft. And we cannot use the Assets directory because there is a AssetStoreTools directory, otherwise this directory will be included in the draft package.

This was the response:

Actually, the Asset Store Tools were written to ignore themselves. It is indeed very confusing, but when you upload your assets you can select the root Assets directory.

This, however, causes another issue (particularly with older versions of Unity) in that your users will see collisions between the Gizmos, Plugins, Plugins/Editor, Editor Default Resources, etc. Folder Assets (folders have GUIDs, too) when they already exist in the project into which they’re importing. In Unity 5.2.x and earlier, this could cause asset reimportation and the spewing of lots of errors. Recent versions of Unity (5.3.3 [at least], and 5.4beta) no longer throw errors or trigger reimportation but will show you the collision and warn about it in the Package Importer window. I have an open bug report with Unity about this (Case 776565). The simple solution to this is to allow us to select multiple root folders for our assets in the Asset Store Tools.

[IsaiahKelly]

According to the manual, the phases of script compilation are as follows:

Phase 1: Runtime scripts in folders called Standard Assets, Pro Standard Assets and Plugins.

Phase 2: Editor scripts in folders called Editor that are anywhere inside top-level folders called Standard Assets, Pro Standard Assets and Plugins.

Phase 3: All other scripts that are not inside a folder called Editor.

Phase 4: All remaining scripts (ie, the ones that are inside a folder called Editor).

So apparently the following locations are also valid for first-pass editor script compilation:

Editor Scripts:

• Assets/Standard Assets/**Editor**/[Package_Name]/...
• Assets/Pro Standard Assets/**Editor**/[Package_Name]/...

However, I’ve noticed that when importing the standard assets an editor folder is created in the root of the project. Does this mean editor scripts placed there are also processed first?

Editor Scripts: Assets/Editor/[Package_Name]/… ???

The manual does say editor folders “anywhere inside top-level folders” are included in phase 2, but omits the root Asset folder from the listed locations (simple oversight perhaps?). But if Unity is placing scripts there then I would assume this is indeed the case.

[SonicBloomEric]

Hi @IsaiahKelly ! This is indeed a confusing part of the manual. I will do what I can to straighten things out.

@IsaiahKelly

However, I’ve noticed that when importing the standard assets an editor folder is created in the root of the project. Does this mean editor scripts placed there are also processed first?

The short answer is “Yes”. The longer answer is “there are multiple firsts”.

The four phases mentioned in the manual actually equate to four separate assemblies. If you place scripts in all four sections within a single project, you will notice the following layout in MonoDevelop/Visual Studio:

Here’s a breakdown of the four assemblies:

• Assembly-CSharp-firstpass - [Phase 1] - This is all C# scripts beneath Plugins, Standard Assets, and Pro Standard Assets, not in an Editor folder.
• Assembly-CSharp-Editor-firstpass - [Phase 2] - This is all C# scripts beneath the folders mentioned in #1 that happen to also have an Editor folder in the path somewhere (see the note about Unity 5.2.2 for how this differs with earlier versions).
• Assembly-CSharp - [Phase 3] - This is where all C# scripts not in Plugins, Standard Assets, and Pro Standard Assets are handled. Note that if scripts are within an Editor folder at some level, then they end up in #4.
• Assembly-CSharp-Editor - [Phase 4] - This is where all C# scripts beneath Editor folders that are not in Plugins, Standard Assets, and Pro Standard Assets are handled.

Note that these assemblies are scripting-language-specific. In the list above, all scripts in the project are C#. If you have Boo or UnityScript files you will see similar assemblies appear in the above list with older versions of MonoDevelop__*__. E.g. Assembly-Boo and Assembly-UnityScript.

This is the system that enables cross-language support: when compiled, the scripts are converted into a Common Intermediate Language (IL). As compilation passes are aware of IL, each subsequent pass can reference earlier passes, regardless of the initial language. This is specifically how the firstpass assemblies enable cross-language development.

*Newer versions of Unity now appear to mainly support C# with the IDE (MonoDevelop/Visual Studio) and have dropped deep support for Boo and UnityScript (JavaScript). These languages still compile, but they do not show up in the Solution browser within MonoDevelop (at least by default).

@IsaiahKelly

The manual does say editor folders “anywhere inside top-level folders” are included in phase 2, but omits the root Asset folder in the listed locations (simple oversight perhaps?). But if Unity is placing scripts there then I would assume this is indeed the case.

What’s happening here is that these are ending up in Phase 4 instead of Phase 2. I’m unsure as to why this is necessary - it’s possible that it was a simple oversight or perhaps implemented by someone who didn’t fully understand the compilation passes (as pointed out in the initial post, even core Unity engineers aren’t fully aware of how this all works together).

I imported the current Standard Assets to run a quick test. As expected, the solution contains projects for phases 1, 3, and 4. I moved the Editor folder into the Standard Assets folder and updated the solution. As expected, the projects were now for phases 1, 2, and 3. No errors occurred in doing so, so it appears that this should work absolutely fine.

As a heads up, moving scripts into firstpass compilation will help reduce the amount of time your main project scripts take to compile when they change.

[IsaiahKelly]

Thanks for doing such a detailed investigation into this @SonicBloomEric !

@SonicBloomEric

What’s happening here is that these are ending up in Phase 4 instead of Phase 2. I’m unsure as to why this is necessary - it’s possible that it was a simple oversight or perhaps implemented by someone who didn’t fully understand the compilation passes (as pointed out in the initial post, even core Unity engineers aren’t fully aware of how this all works together).

I imported the current Standard Assets to run a quick test. As expected, the solution contains projects for phases 1, 3, and 4. I moved the Editor folder into the Standard Assets folder and updated the solution. As expected, the projects were now for phases 1, 2, and 3. No errors occurred in doing so, so it appears that this should work absolutely fine.

How bizarre. The placement seems deliberate, since it would seem to go against both natural instincts and the official manual. The VR sample assets place the editor folder in the root too. Does Unity know something we don’t? In any case, Unity developers do seem to lack a bit of consistency, so maybe this is just an oversight.

Thanks anyway for trying to get to the bottom of this though. Very helpful information.

[SonicBloomEric]

@IsaiahKelly

Thanks for doing such a detailed investigation into this @SonicBloomEric !

No problem. It took me a while to figure this stuff out and I’m more than happy to share with the wider community.

@IsaiahKelly

How bizarre. The placement seems deliberate, since it would seem to go against both natural instincts and the official manual. The VR sample assets place the editor folder in the root too. Does Unity know something we don’t? In any case, Unity developers do seem to lack a bit of consistency, so maybe this is just an oversight.

Yeah. To that end I filed a bug about it (Case 813847). If they respond with a reason for this to be at the root, I’ll update here with their explanation.

[SonicBloomEric]

@SonicBloomEric

To that end I filed a bug about it (Case 813847). If they respond with a reason for this to be at the root, I’ll update here with their explanation.

Update: The bug report received the following response from Unity QA:

For now you can move Editor folder to Standard Assets folder manually. Our developer will fix it and fix should appear in 5.5 / first 5.4 patch.

It seems that not having the Editor folder within the Standard Assets folder was a simple oversight.

[jerotas]

I agree with all of this although I had figured it out piece by piece over a few years. Great to see it all in one place!

What sucks is that most plugins still install everything in Assets, not Assets/Plugins for some reason. Either they’re not aware of the compile time problem or something else.

Thoughts? I would like ALL editor extensions to be in plugins. I use tons of them and have to move them manually. Some don’t work properly in there either (maybe hard-coded paths or something).

[SonicBloomEric]

@jerotas

Thoughts? I would like ALL editor extensions to be in plugins. I use tons of them and have to move them manually. Some don’t work properly in there either (maybe hard-coded paths or something).

I’m 99% certain that there are a few things going on here (in order of likelihood):

• Poor Communication: Unity does not communicate the existence or purpose of the Special Folders well. This applies to both the Manual and the Editor itself. Why don’t Special Folders have separate icons in the Project View? Why don’t they have Tooltips that describe (or even hint at) their purpose? Why doesn’t the Plugins page make mention of non-DLL plugins?
• Poor Workflow: Unity does not explain how to use the Asset Store Tools well. The Asset Store Tools only allow the user to specify a single folder. If you use the Special Folders correctly, this must be the root Assets folder. Many people try to upload their extensions from their development folder which likely has other stuff in it. To deal with this they probably find it easier to simply move everything into a single folder and call it a day. It works, right?
• Poor User Experience: I’m sure you’ve experienced this but users sometimes move the folders into a single root directory of their own choosing and things break. With our packages, this is due to icons/skins being moved out of the Editor Default Resources folder. The natural thing to do is to put everything under a single product’s folder and code it in such a way that the whole thing is location agnostic (which can be pretty challenging).

When I first started using Unity, I would move extensions into a folder of my own choosing. Some worked and, as you have described, some failed spectacularly - so much so that I had to simply delete everything and reinstall because I didn’t know how to restore things.

With respect to requiring ALL Editor Extensions to be in plugins, I’m not sure how tenable that is. We put documentation, demo content, and related stuff into a product folder in the root Assets directory. This improves discoverability (as Unity doesn’t have notifications on folders for “new” or the like) and also means that users are free to destroy the root folder, removing all the extra “bloat” content and leave everything in Plugins/Editor Default Resources/etc. running smoothly.

The one thing I might suggest that Unity add to the Submission Guidelines is that any folder placed outside of the Special Folders should be relocatable without breaking the asset.

Apparently Unity is working on this problem, but the whispers I’ve heard don’t lead me to believe we’ll see any big changes soon.

[compressedFusion]

@SonicBloomEric

The [Wrong] Default Approach

Editor Scripts: Assets/[Package_Name]/Editor/...
Editor Resources: Assets/[Package_Name]/Resources/...

It turns out that this actually has two pretty surprising problems:

• If the package has scripts and supports an API, only the original language the API was written in can be used to interface with it. This has to do with the Script Compilation Order.

I agree with the Resources but this seems like the correct solution for editor scripts that don’t need to be accessed as an API. Could you elaborate on the use case in which the editor script needs to be accessible as an API in C# or JS? I would assume a custom inspector or custom SceneGUI doesn’t typically fall under this category.

[SonicBloomEric]

@compressedFusion

Could you elaborate on the use case in which the editor script needs to be accessible as an API in C# or JS? I would assume a custom inspector or custom SceneGUI doesn’t typically fall under this category.

The use case for Editor Scripts being accessible as an API relates to Editor Extensions and, more generally, anything that has a special component (MonoBehaviour) with public functions you may want to control with script. You can write a MonoBehaviour in Boo, right? Putting it in the firstpass compilation pass makes those functions callable with whatever language the user likes.

I should also mention that there’s another benefit to all of this: your scripts do not add to the amount of time it takes to compile a project when a user makes a change to a script outside the firstpass compilation passes (outside of Assets/Plugins). While this is almost imperceptible on small prototype projects, it can seriously add up for larger projects. This is simply part of being a nice neighbor. Firstpass scripts are only recompiled when other firstpass scripts are changed.

I would suggest that the only time to not put scripts in the firstpass locations is when you want to provide your users with scripts that they should edit or configure themselves.

Make sense?

[compressedFusion]

@SonicBloomEric

…Editor Extensions and, more generally, anything that has a special component…Putting it in the firstpass compilation pass makes those functions callable with whatever language the user likes.

… another benefit to all of this: your scripts do not add to the amount of time it takes to compile a project when a user makes a change to a script outside the firstpass compilation passes …

I would suggest that the only time to not put scripts in the firstpass locations is when you want to provide your users with scripts that they should edit or configure themselves.

I suppose there is no way to know if your editor will eventually need to support extensions by the community such as playmaker. So, you make a good point.

I agree with the compile time.

Your logic makes sense in principle, but the situation in practice might be somewhat different. The two fundamental issues are:

1.) The plugins directory forces an illogical separation of code and fosters controlled chaos (or disorganization). It also separates the asset as a bundle when trying to remove it or track down a dependency.

2.) I almost always have to tweak something in an asset to meet my needs or deal with a conflict. This problem is compounded by Unity version differences.

All of this could be mitigated by better tools to display the dependencies of an asset as a logical unit of code/models/fx. I have tried to use assets like RelationsInspector (I used the free trial version) to help manage this but I didn’t have much luck on my more complicated dependencies.

This lack of structure is a real issue that arguably costs more time than constant recompile.

I’m curious if you have run into similar issues with organization and project asset flux.

[SonicBloomEric]

@compressedFusion

The plugins directory forces an illogical separation of code and fosters controlled chaos (or disorganization).

On the contrary, the separation is very logical - it simply isn’t communicated well and, currently, requires that users somehow already understand something that I’d argue most Unity employees don’t even understand. Unity didn’t randomly build their technology this way - there was a purpose. They just didn’t follow through on the communication side of things.

That said, I do agree that it is an unnecessarily complicated, legacy architecture that does not adhere to good UI principals.

@compressedFusion

It also separates the asset as a bundle when trying to remove it or track down a dependency.

If asset developers follow the structure outlined in this document you should be able to quickly find all root packages by simply typing the package name into the Project view’s search box. In terms of script dependencies, wouldn’t it be faster to search for symbols within scripts using MonoDevelop/Visual Studio/your-favorite-IDE? Theoretically, non-script asset dependencies would all live in the main root folder which you could move about freely (the exceptions here being assets that need to live in Gizmos or Editor Default Resources).

@compressedFusion

I almost always have to tweak something in an asset to meet my needs or deal with a conflict.

I take it you’re suggesting that breaking up the package into multiple folders makes locating the specific asset to tweak is a hassle, yes? That is a pain, but I believe the theory behind the initial structure of all of this was that scripts for packages would be under Plugins and everything else would be under a single package location (same exceptions as previously mentioned). If everyone followed this setup then this would be easier to mitigate. They don’t, however, which means that it’s somewhat of a crapshoot (one good reason to do this is if you are a company that provides multiple packages that can work together. In that case people typically do [Company]/[Package Name] instead of just [Package Name]).

@compressedFusion

This problem is compounded by Unity version differences.

Oh my, yes. This is also why the Unity Asset Store allows you to upload your asset with multiple versions of Unity. Take one of our packages for example: we upload with Unity 4.5.0, 4.6.0, 5.0.0, 5.1.0, and 5.4.0 to properly support all the variations. We jump through several layers of hoops with our build system in order to make this all work. It is most definitely a pain when asset publishers don’t update their package frequently enough to handle Unity changes.

@compressedFusion

All of this could be mitigated by better tools to display the dependencies of an asset as a logical unit of code/models/fx. I have tried to use assets like RelationsInspector (I used the free trial version) to help manage this but I didn’t have much luck on my more complicated dependencies.

Yeah, this is certainly annoying. The AssetDatabase does not have provide a mechanism to locate assets that make use of a specific asset. In the past I’ve found that using the Version Control→Mode→Visible Meta Files and Asset Serialization→Mode→Force Text settings in the Editor Settings allows you to use standard OS tools (e.g. grep in OSX) to search for dependencies outside of Unity. This, of course, is a very manual process but it does work.

@compressedFusion

This lack of structure is a real issue that arguably costs more time than constant recompile.

Perhaps in extreme circumstances, but I’ve not found the organization to be that much of a problem (at least once I understood more about how everything worked!). Generally assets work pretty well and clickable errors in the Console help to bring you directly to offending assets/scripts. But my experiences are my own and I do not claim to speak for the entire industry. In principle I completely agree with you.

@compressedFusion

I’m curious if you have run into similar issues with organization and project asset flux.

With other assets, yes. The biggest headache I’ve personally dealt with is trying to get multiple assets that make use of different versions of the Standard Assets to play nicely together. This issue is compounded when Asset Publishers mess up the GUIDs of shared assets (e.g. Standard Assets) when uploading to the Asset Store.

[IsaiahKelly]

I came across this in the Asset Store guidelines:

3.1.c If your submission requires specific folders to be in the project’s root, such as a “Plugin” or “Editor” folder, you will need to include instructions in your documentation telling users to place these folders in the proper location manually. See the Unity documentation for Special Folders and Script Compilation Order for more information.

This is a bit confusing. Does this mean we should not place assets inside any of the special folders, and just tell users to move them there manually instead? They don’t explicitly say special folders, but do refer to them. However, saying “specific folders to be in the project’s root” is really ambiguous and can’t mean just any root folders, right?

In any case this doesn’t make much sense to me because aren’t plug-ins required to be placed in the plugins folder? And if they’re not talking about special folders then what exactly are they talking about?? Maybe they just mean multiple root folders???

[SonicBloomEric]

@IsaiahKelly

This is a bit confusing. Does this mean we should not place assets inside any of the special folders, and just tell users to move them there manually instead? They don’t explicitly say special folders, but do refer to them. However, saying “specific folders to be in the project’s root” is really ambiguous and can’t mean just any root folders, right?

This is a very unfortunate and not-well-thought-out clause in the revised Asset Store Submission Guidelines. It was immediately brought up as a concern in the Asset Store Publisher’s list given that this structure has actual utility and @Ian_Dunlap responded with:

The main point of [3.1.c] is to avoid publishers from dumping content throughout a project unknowingly to the user. But it’s completely understandable the points you brought up where that’s just how Unity is structured and absolutely a good point that the more steps a user is required to take, the more likely it is for user error and negative impressions. We will try to clarify and reword that one.

They have yet to make any adjustments to it.

This effectively stems from internal Unity employees not understanding the purpose and utility of these folders. I have been told that changes are in the works to help fix this situation.

@IsaiahKelly

In any case this doesn’t make much sense to me because aren’t plug-ins required to be placed in the plugins folder? And if they’re not talking about special folders then what exactly are they talking about?? Maybe they just mean multiple root folders???

It’s the multiple root folders that they were trying to avoid. I’m pretty sure they just noticed that a bunch of people seemed to be using Assets/Plugins and called it out specifically without realizing the purpose behind those folders (especially for older Unity versions). In short, you are okay to use the folder structure outlined in this thread - the Asset Store team is aware of it and I’ve been told they are working on fixing both the guidelines and the underlying systems to be more user friendly.

[IsaiahKelly]

Based on the information in this topic it seems like the Asset Store team is trying to avoid folder GUID conflicts that result from multiple asset packages using the same special folders. Specifically the very common “Plugins” and “Editor” folders in the root. Unfortunately, I think they’ve completely failed to articulate this and should probably rewrite that section to say something like this:

If your submission requires the use of common folders in the project’s root, such as the “Plugins” or “Editor” folder, it’s best to include instructions in your documentation telling users to place these folders in those location manually to avoid conflicts with preexisting folders upon import.

@SonicBloomEric

The biggest headache I’ve personally dealt with is trying to get multiple assets that make use of different versions of the Standard Assets to play nicely together. This issue is compounded when Asset Publishers mess up the GUIDs of shared assets (e.g. Standard Assets) when uploading to the Asset Store.

Yeah. This issue is directly address in the Asset Store Guidelines now and further confirms my assumption that they’re trying their best to avoid these GUID conflicts with submitted packages as much as possible.

3.1.e To avoid inconsistencies during importing, Do not include “Standard Assets” folder in your submission. If you have a demo scene that utilizes any “Standard Assets”, include documentation as to how you setup your scene and allow for the user to import the “Standard Assets” themselves.

[IsaiahKelly]

However, I have something of a dilemma now: Do I place my editor extension inside the “Plugins” folder and risk throwing import warnings, in exchange for some benefits my extension might not even take advantage of?

[SonicBloomEric]

@IsaiahKelly

Based on the information in this topic it seems like the Asset Store team is trying to avoid folder GUID conflicts that result from multiple asset packages using the same special folders. Specifically the very common “Plugins” and “Editor” folders in the root.

I do not think this is the case. In Unity 5.3 and above, the import process shows a warning during GUID conflicts like this but otherwise doesn’t complain. This is not a terribly great way to address the problem, but it is what it is. Essentially, the importer has been updated to minimize the visible impact of GUID conflicts during the import process.

The Asset Store team [and asset publishers, to be sure!] would prefer that every asset is installed in a single root folder and that the folder be immune to relocation. Many customers have their own specific project layout and like to move third party assets into a particular structure (e.g. Assets/Third Party/...). Every few months we get a bug report about a plugin not working and this is because someone moved things around because they didn’t understand that the special folders were indeed special (and functionally so). We never blame the customer for this as the lack of useful, communicative UI in this department is entirely on Unity’s hands.

[I should note that the Editor folder never needed to be in the root folder. The one restriction (until 5.2.2) was the Assets/Plugins/Editor folder. Editor Default Resources, on the other hand…]

@IsaiahKelly

Unfortunately, I think they’ve completely failed to articulate this and should probably rewrite that section to say something like this:

If your submission requires the use of common folders in the project’s root, such as the “Plugins” or “Editor” folder, it’s best to include instructions in your documentation telling users to place these folders in those location manually to avoid conflicts with preexisting folders upon import.

I think this is entirely the wrong way to go. Users should not need to read documentation to help them get something installed correctly. Unity should rather ask that Publishers make proper use of the Special Folders. Unity themselves should then put real effort into:

• Communicating the nature of the Special Folders to both publishers and users (but especially publishers).
• Fixing the Asset Store Tools to either be properly aware of Special Folders or allow for multi-root selection (Case 776565).

In that way both publishers and users would benefit from the rules.

@IsaiahKelly

@SonicBloomEric

The biggest headache I’ve personally dealt with is trying to get multiple assets that make use of different versions of the Standard Assets to play nicely together. This issue is compounded when Asset Publishers mess up the GUIDs of shared assets (e.g. Standard Assets) when uploading to the Asset Store.

Yeah. This issue is directly [addressed] in the Asset Store Guidelines now and further confirms my assumption that they’re trying their best to avoid these GUID conflicts with submitted packages as much as possible.

Clause 3.1.e does indeed address this issue. The problem here isn’t necessarily GUID-related, however, but Standard Asset version differences. If you import a package that includes Standard Assets from a different version of the Standard Assets package, one of several things can happen:

• The GUIDs are the same as the version Unity ships - the version in your local project is updated with the older or newer version that may introduce conflicts or otherwise be incompatible with the version of Standard Assets you installed.

• Note: This can be extra bad in the case that the version of assets you install was actually for a different version of Unity (e.g. older asset uploaded for 4.x imported into a 5.x project).

• The GUIDS are different from the version Unity ships (the publisher copy-pasted the assets, dragged them in from a different project, etc.) - you end up with assets that have the same name.

• If they’re in the same folder, they may overwrite and you end up with the same issue above (as well as broken prefabs, etc.).

• If their location is different from the main Standard Assets location, you end up with duplicates. This probably isn’t that bad unless scripts are included, at which point you end up with either duplicates (possibly in different compilation passes) or compilation errors because the classes are already defined.

All of the above scenarios (GUID conflicts or no) are sidestepped by Clause 3.1.e.

That said, GUIDs are a huge problem for Publishers. I’ve heard that some publishers find managing them properly too large a hassle and simply instruct their users to delete the asset before reimporting for an update. This route is awful because when the GUIDs do change, external linkages all break during the update process. I don’t necessarily blame people for not understanding how GUIDs work within Unity and the greater Asset Database - they do a terrible job explaining them:

• “GUID” does not appear in the Submission Guidelines (at time of writing).
• The AssetDatabase Manual page mentions “metadata”, but not GUID (except as they appear in script calls).

In fact, the best resource I found that actually covers GUIDs is this external blog post. It’s somewhat shocking that Unity doesn’t cover this core piece of how the engine actually works.

@IsaiahKelly

However, I have something of a dilemma now: Do I place my editor extension inside the “Plugins” folder and risk throwing import warnings, in exchange for some benefits my extension might not even take advantage of?

Use the Plugins folder only if there is a reason to do so (script compilation firstpass, Unity 4.x build requirements). Otherwise, I would suggest sticking with the “Assets/[Package_Name]/...” setup. The import warnings have been all but eradicated by recent Unity versions (5.3+) such that all your users will see is a little warning triangle in the importer window (which they likely won’t even notice).