Example Project - Assembly Definition Files

1) We have it on our backlog to visualize the assembly dependencies in Editor. For now you can get the assembly dependency graph using https://docs.unity3d.com/2017.3/Doc...lation.CompilationPipeline.GetAssemblies.html and potentially visualize it yourself

2) You have to be careful with where you put the .asmdef file in existing projects, because if the subfolders use the editor/plugins folders, then these won't work for .asmdef files and require you to explicitly add the .asmdef files to those folders. Also, the precompiled .dlls might be referencing Assembly-CSharp and friends, as seen previously in this thread. The editor.log will have additional information about missing dependencies for precompiled dlls and details for compile errors that are not emitted to the Editor console.

 

Your notes all make sense, and thanks for that. The first bit I highlighted here is pretty critical information, I think, and the latter is still quite useful for a lot of people making any sort of editor functions. I've noticed some oddness with it from time to time myself, but assumed I was doing something wrong (probably still was).

Oof -- this one is something I'd strongly recommend you guys look at use cases for, because it's going to be a massive pain. The Editor folders are the only magic ones that matter for these purposes.

But in this particular case, let's say I have a project with a variety of asset store tools in it. In fact, I do. Some of them I break out into having their own asmdef files in root folders to save compile time, and others I move into a ThirdPartyHelper folder that has its own global asmdef folder for all of the assets within that.

So far so good... but when it's time to compile a standalone build, I immediately have 632 errors relating to "CS0246: The type or namespace name `UnityEditor' could not be found." Which I understand why that's there... but only because you noted that the magic folders stop working inside folder trees with an asmdef directory. I wouldn't expect most to work there, but Editor... boy that's fundamental.

At this point I have two choices. There are 31 distinct Editor folders I have, ranging from those used by Alloy to UBER to Fbx Exporter to pieces of other post-processing stacks.

Choice number one is that I can go in and add an extra asmdef file to EVERY editor folder. I don't know how that will affect performance (having so many assemblies to reload), but it will make my visual studio solution a nightmare for sure.

Choice number two is that I can go in and start moving those editor subfolders for all those assets into a consolidated central few locations. That will work, but then I have to go in and make a bunch of assembly references by hand and check all the assets to make sure that if there are any hardcoded file paths that those get updated to the new location, etc.

On this general subject, incidentally any precompiled C# dlls that are in subfolders of an asmdef tree don't get properly loaded. So those have to be moved out, too.

At this point my compilation time is down, but every asset is now spread across two or three folders for its dlls, runtime-okay code, and editor-only code. Not sure how I feel about that, but I think it will throw a lot of people for a loop.

I'm going to opt for choice number two above, and then just keep track of where I put things from now on. But it would be helpful (as yet another aside) to have some indication that builds are going to fail because of the current folder layout prior to me trying a build.

Anyway, I know this sounds like a lot of griping, and it is, but I am head over heels for the work you guys are doing here. All of this is small nitpicking in the end, for me at least.

 

I did this in one project and it turned out to be a nightmare. Updating those assets became a tremendous effort and error prone. I won't do this again.

 

It is a nightmare, but it's one that source control thankfully helps. Without svn diffs I'd never be able to manage it -- not remotely. At any rate, right now it's my best option I think.

 

Normally we have multiple editor folders in different hierarchies so it's really difficult to do this or we are forced to maintain a single editor folder with all scripts inside of it.

 

Going to second that. We have all our editor scripts in an editor folder next to the script it edits. It's not impossible to retrain to instead have a matching editor hierarchy, but I prefer having the editor script close by.

The biggest reason to allow assembly defenitions to have an editor and a non-editor version of the assembly based on magic folders is that it reduces the amount of work required to update asset store packages. You could essentially automatically put an asmdef file in the root of each package and it would just work. Right now, on the other hand, the situation is that if the author of the package has used the editor-next-to-script setup, they'll have to reorganize their entire folder structure.

You could also do this as an option in the asmdef file, which would allow people to change this behaviour depending on what they're looking for.

 

Just another workflow observation -- I'm not really going to call this a bug, but it's something that is going to lead to a lot of false bug reports for you guys over the next year, I think.

Basically this is what happened:

1. I created an UBER folder, with an UBER.asmdef file in it for the uber post processing framework.

2. I realized the issue with Editor folders not being magic anymore inside subfolders like that. But it's not just that folder, it's a ton of folders.

3. So I start moving things into a new ZEditorGroup folder with a ZEditorGroup.asmdef file. The latter is set to only include the platform of Editor.

4. At this point things are working well as I move them over, and my compiler error count is going down (but I have to do a build each time to get a list of things that are broken.

5. During this process I wind up moving the aforementioned UBER folder into my ZEditorGroup folder... but I forget to delete the UBER.asmdef file in there. Oops on my part, obviously.

6. Now when I do builds, everything else in the ZEditorGroup folder is working fine, but stuff in the UBER subfolder is still freaking out not being able to reference things in the UnityEditor namespace. I've done too much other work to notice that UBER.asmdef file, and there's no indication in the error messages that this is being compiled into the UBER.dll rather than the ZEditorGroup.dll -- otherwise I would have cottoned-on immediately.

7. At this point I start thinking it's because of the fact that part of the UBER files are declared in the UnityEditor namespace themselves, or because they use some pieces that don't have a namespace, or even because they're using some editor classes that they're declaring as internal (I'm sure there must be some bug here, so I'm basically trying to figure out what makes these files different from everything else). Eventually I find that UBER,asmdef file, delete it, and all is well. But I was about to make a bug report about one of the above theories, since it seemed to be something strange like that.

I predict a lot of bug reports of those sorts headed your way, but as noted in #6 a slight adjustment to the error message output can head all those off.

 

Another question I have, regarding "magic folders." Are the ones that are not code-related still functional even when they are in asmdef-rooted folder trees? The biggest deal here is all the many Resources folders that are scattered around most projects and assets.

They'll have the same problem as the Editor folder if that particular function doesn't still work -- that's simply a non-code-asset function anyhow, though, so I'm hoping the answer is that it works the same either way. I think the only other non-code one is Gizmos, but frankly I've never really messed with that one so I don't have much knowledge on how it's supposed to behave anyhow. I guess also Editor Resources, though it's more rarely used.

 

Let me just clarify that .asmdef files overriding behaviour for the magic folders is only for script compilation. Any other systems such as plugins and resources that also use magic folders are not affected by .asmdef files, as these are separate systems that just happen to share the same concept of the magic folders with similar names.

The general consensus by people who replied in this thread yesterday seems to be that migrating to .asmdef files for existing code is difficult and that having special logic for at least "editor" folders would reduce the migration pain.

If we consider how the inspector for the .asmdef files is implemented today, then if we create an special/in-memory .asmdef file, we would not be able to select it as file in References. We could work around this by adding special handling in the UI. However, it would be odd for some one who just looks at the .asmdef as files on disk and sees a reference to an assembly for which there is no .asmdef file. I think this implicit behaviour is somewhat confusion and is similar to how to the magic script folders work. One of the goal with the .asmdef files was to move away from implicit behaviour and towards very explicit behaviour.

The other thing to consider is, if we added special handling for the "editor" folders and magically outputted an MyAssembly.Editor.dll, how would this actually be implemented in the compilation pipeline? The way it would work is that we would collect all the scripts in "editor" and subfolders inside .asmdef defined folder and compile these scripts into an separate assembly and create an in memory .asmdef file for these scripts.

Collecting all the scripts in the "Editor" folders and compiling them into a MyAssembly.Editor.dll assembly would be equivalent to just have some tooling that did the same thing on the file system. E.g.

1) Collect all editor scripts.
2) Move them into an "MyAssembly.Editor" folder under the "MyAssembly" .asmdef folder.
3) Add MyAssembly.Editor.asmdef file to "MyAssembly.Editor" folder and reference it from the the "MyAssembly" .asmdef file.
4) Possibly add additional references to MyAssembly.Editor due not-so-well-defined dependencies. This would also be necessary with the automatic solution.

The .asmdef system imposes some constraints on how you organize your scripts, like the magic script folder system does and the two systems have different approaches, making switching manually from one to the other difficult. Since it is possible to address some of the migration issues with tooling and it would be similar to how it would be solved with a permanent migration feature inside the editor. And since the tooling solution is a better fit for how scripts should be organised with the .asmdef feature going forward. I'm leaning towards not providing a permanent migration feature in editor and instead encourage the use of tooling for address these pain points.

Let me know what your thoughts are on this

Adding the assembly name to the error messages has been requested previously in this thread and it is on my backlog.

 

I think the tooling solution will be fine.
It'll be more cumbersome to convert old projects than if the magic Editor name still worked. It'll also make creating an editor script take a bit more time, since I can't just find/create an Editor folder right next to the file and dump the Editor script there. But none of these are breaking changes, they're just quite cumbersome to handle. A tool to introduce an asmdef in a folder and then also introduce editor-asmdefs won't be very hard to make.

Having a uniform system is cleaner. The big elephant in the room now is magic folders in general - will you be looking into removing the concept of an Editor folder in the long run? It's always been a very hacky solution, we've just gotten so used to it and worked it so much into our flow that it's hard to make the switch.

 

I use #if UNITY_EDITOR and functionality from the UnityEditor namespace inside such #if block in various non-editor code files. It's actually "run-time" code, but with additional debug code if it runs in the editor for example.

Is this still supported if I use .asmdef files?

 

Hey, @lukaszunity

I'm sorry if I missed a discussion about this, but is it possible to reference Unity Extensions from the scripts placed to the Editor folder and wrapped with asmdef?

I've noticed such case:
Some file is placed at
Assets/Plugins/SomeName/Editor/Magic.cs

It has such using:
using UnityEditor.UI;

And it stops to "find" it as soon as I add asmdef to the SomeName folder.

I've also noticed this namespace is placed at the separate assembly at
C:\Program Files\Unity 2017.3.0\Editor\Data\UnityExtensions\Unity\GUISystem\Editor\UnityEditor.UI.dll
So looks like I need to reference it somehow, but how?
Is there any workaround for this?

Thanks!

 

Thanks for the notes, Lucas -- you make a lot of really great points. Also, thanks for clarification on Resources, etc. And obviously you've been thinking about this whole thing way longer than any of the rest of us.

When it comes to migration, having a file-system tool that did that would indeed solve the problem much the same way. Though honestly I think for most projects it's just as easy to do it by hand at that point unless you're not using source control or you have a truly huge number of third party extensions in play.

All of that said... I'm torn. I get the feeling that you have a bit of an ideological rankling at the concept of magic folders, and to be frank that's a sentiment that I generally share. When first starting to use Unity, I thought it was absolutely horrible.

The main challenge, however, is that we start getting caught in the middle of three kinds of semantics.

1. Having things act in a clearly-defined and deliberate way -- aka, no magic folders. I'm definitely for this, on principle.

2. Having as few resulting as dlls as makes sense per project, which is going to vary by project. Essentially we don't want to be having 40 sub-projects inside one solution, or solution reloads will take forever. On the flip side, looking at this from the perspective of doing away with magic folders, just moving all our scripts into folders organized by dll purpose makes perfect sense. Again -- on principle, I'm completely for this, and with my own code I have no problem with that.

3. When it comes to third-party assets, which are basically unavoidable for any serious project or even non-serious ones, though, we get into a major organizational kerfluffle. From that standpoint, the magic folders were nice because they were essentially content aggregators to fulfill the goals of as few dlls as possible, but they let us keep code groups together -- one asset from the store could have ALL its code in a single directory tree, and in fact it is major black marks in my eyes if an asset doesn't follow that pattern. On principle, I still think that having all the content for a given third party asset inside a single folder is a really good idea... but I don't want to be recompiling that with every time I make a change to my own code.

---

Basically what you're asking us to do right now is give up on semantic #3 there. And I can see the reasoning behind that -- from an engineering standpoint, it's a lot cleaner. From a project organization standpoint, it is arguably messier, though. It's semantics, and we can re-train ourselves, but that's my thought at the moment.

I'm not angry about this shift and I can easily live with it, but mainly that's because I'm already used to digging into the code of anything I put in my project, and moving things around. For people who want to just "import and go," they're going to have some rude awakenings.

A variety of asset store tools have some pretty unfortunate behaviors that are linked to specific locations. Here are some big ones off the top of my head:

1. Rewired wants to have _everything_ all in one folder, in a very specific folder tree. I've actually contacted the author about that, in relation to asmdef issues that's causing. I've gotten Rewired working with the asmdef situation, but during every play in editor mode it throws errors because it can't find some dlls that are in the correct place, but the presence of the asmdef file breaks the ability to find them. Managed dlls inside a folder tree with an asmdef above them don't work quite right... kinda-sorta. I can't honestly pin down what the behavior here is yet, but generally moving those dlls out into another folder is a good idea. With Rewired they have some hardcoding going on inside their dll, which means I can't even change the code. This is the only asset quite so inflexible that I know of.

2. Only semi-relevant, but will be a pain for non-coders trying to move things around: Alloy has over a hundred hardcoded references to various specific files at specific relative locations to Assets. It even has a hardcoded reference to the location that an Hx Volumetric Lighting file would be if the latter is installed. For a lot of the asset cross-compatibility stuff, particularly that is shader-based, that's how authors are doing it. It's mostly an unfortunate design on their part, but since shaders can't use relative paths super duper well, the best way to reference cginc files is unfortunately either by having them all in one folder or by doing pretty direct referencing. Alloy is such a problem because it has a huge number of shader variants, optimized for different purposes.

3. UBER uses a managed file called SimpleMatrixLibrary.dll. The classes from that file cannot be found until the managed dll is moved out of the UBER folder with the asmdef file into some other location. You know... it may actually be possible to do that, and then move it BACK in, since once a folder compiles once as an asmdef assembly I think that child managed dlls might be loaded properly. So maybe that's actually the bug, I'm not positive -- that basically an asmdef folder can't compile because it's not yet loading the child managed dlls in that same folder that it's dependent on. But once it has compiled, that catch-22 goes away and all is well. That's probably what was going on with Rewired as well, although there's something even worse there that still throws errors, and that's something I just need to work out with that asset's author.

---

TLDR:

1. Right now, this is going to confuse non-coders.

2. Non-coders are going to want to use asmdef files because they want things to compile fast the same as coders would.

3. Coders who don't use source control are going to percieve this as a nightmare to keep track of assets that they split out by hand.

4. Anyone who uses third party assets will have to redo a lot of manual legwork such as global find and replaces for hardcoded paths and such every time that asset is updated, which can be pretty frequently. I guess we'll have to start taking notes on what to do for each asset, so that we don't have to keep re-figuring-it-out. Though source control kind of takes that guesswork out for you, if you do a diff after importing but before committing.

5. In general, I think that most coders are going to appreciate the lack of magic folders, and that part is going to be less confusing for everyone. (Yay!)

6. That said, I think that most coders are going to feel like having assets spread across multiple folders is spaghetti code, organizationally-speaking. It's technically not, but it can sure look like a mess.

7. None of this is a crisis in my opinion, and definitely not a reason to delay release of this or anything (please don't!). What you have works well, and is pretty straightforward to learn, even if there are some kinks in the system at the moment.

Sorry for the length of this, but hopefully it helps a bit.

 

We probably will never get rid of the magic folders because to remain backwards compatible. We might encourage developers creating new Unity project to use .asmdef files by for instance creating by creating "ProjectName.Runtime" and "ProjectName.Editor" folders with .asmdef files in them by default.

 

.asmdef assemblies are compiled in the same fashion as Assembly-CSharp and friends, so this work the same. We also reference UnityEditor.dll for all .asmdef assemblies inside the editor, like we do for Assembly-CSharp.dll.

 

I'm not sure I completely understand all the points this message is trying to get across, but I will try my best.

Are you worried that we will get rid of the magic folders completely? This will probably never happen. Assembly definition files are just a opt-in optimization for developers who want to cut down on iteration times. You can keep using the built-in magic folders if you prefer.

Regarding solution reloads taking a long time, are you talking about reloading solutions in Visual Studio?

Regarding UBER not compiling correctly with an .asmdef file because there is a managed plugin in the folder and it works if you move the managed plugin in and out of the folder, that sounds like bug. The managed plugins are imported separately from scripts and should in no way be affected by .asmdef files. It also does not matter where the managed plugins are for .asmdef files, as they are all passed as input reference assemblies for compilation after being imported.

Let me know if I missed any of your points

 

If the assembly has been marked as being compatible with the editor, then it should also reference UnityEditor.UI.dll. If an editor .asmdef file does not reference it, then it is a bug.

 

Yeah, long post, apologies.

I much prefer the asmdef files, by a mile. The main thing that is good about the magic folders, though is that they allow the creation of one large dll out of many smaller folders. Right now asmdef doesn't allow for that, and so we get stuff strung all over the place.

One theoretical solution would be to have something like "partial asmdef" files, where if you declare multiple asmdef files with the same assembly name, and put a partial flag on them, it combines them as with partial classes in C#. Or you could have "child asmdef" files that basically exist to point to a parent and say "when that parent assembly gets compiled, I just become part of that one."

It's a middle-ground between the magic folders and the need to reorganize everything in order to get Editor folders out of the main dlls. I very much understand your desire not to have to file-scan the entire asset database in order to compile.

Correct. If I install 15 assets, let's say, and they each have a runtime component and an editor component, then I'd need a minimum of 30 asmdef files unless I move folders around. And that's assuming they don't have anything split up into multiple sub-editor folders, which some assets unfortunately do.

At that point, any time I add a new C# file, it will do a VS solution reload of 30+ projects, which will take forever. Not to mention my solution explorer sidebar will be a nightmare that's impossible to find anything in.

Okay, there's almost certainly a bug here. I thought perhaps this was the desired behavior. In this case, some of my concerns can be disregarded -- it's the Editor subfolders thing alone that is now a concern in terms of the intended design. Something like partial or child asmdef files as noted above would solve that one thing.

As far as this bug, I'll set up a new project and see if I can get a repro case on the bugtracker. I had the issue with Amplify Bloom, UBER, and I think something else.

 

Confirmed the bug. It only applies to dlls that are under a folder named Editor. Quickest way to repro this without the bug report is just to start a new project, import UBER, and then unpack its 01_UBER_ImportFirst.unitypackage file.

Create an UBER.asmdef file at the root of the UBER subfolder. It then has an error that it can't find find some classes that are in the SimpleMatrixLibrary.dll, which is inside UBER/Editor.

If you move that dll into any other folder (root UBER folder, UBER/Scripts, root Assets folder), then all is well. Put it back in the UBER/Editor folder after things compile fine, and it freaks out again.

edit: Bug case number 971715.

 

Thanks for your reply, Lukasz!
I've submitted a bug report with repro case: 971725

 

Rewired does not hardcode file locations and does not force you to keep all the files in the same folder structure. Rewired was painstakingly written to allow it to be run from any folder in Unity. The one single file that it uses the location of is Rewired_Core.dll. Even then, this is not hard coded -- it is detected at runtime based on the location returned by the MonoScript. It uses this file's location to try to determine the location of Rewired root folder in the project so it can do things like install optional packages (touch controls, integrations, etc) into this Rewired folder in a sensible subfolder keeping your project from getting cluttered with other folders, update existing installed packages automatically when upgrading Rewired, etc. By moving the Rewired_Core.dll out of the relative location in the Rewired folder tree, you are breaking it preventing Rewired from being able to determine where its root folder is so it can do all the various asset management in the editor scripts. (This approach was chosen in the first place because the Unity Asset Store does not maintain the asset GUID on the main folder in the asset so the GUID cannot be used as a locator.)

In addition, if you go moving all the files around however you want, you won't be able to update the asset (or any asset) because of how Unity's Unitypackage format works since Unity 5.x. They used to use GUIDs to find files to replace. They no longer do and files must be in the same folder structure or it will duplicate files when the new files are written, generate new GUIDs for them because of clashing with the existing files, and generally cause all kinds of chaos. This applies to updating assets from the Asset Store. See this for more details.

Moving the Rewired_Core.dll into another assembly is also causing everything to break because Rewired's editor DLL need to access to the classes in the core DLL and it also needs to access a class UnityEditorBridge through reflection which it expects to find in Assembly-CSharp-Editor or Assembly-CSharp-Editor-firstpass because this is an editor script compiled by Unity. By moving Rewired_Core.dll into another assembly, it can neither find the required Rewired_Core classes nor can it find the UnityEditorBrdige class which is used to get information from the Unity editor which would otherwise be unavailable from within a DLL (because, for example, preprocessor if's cannot be applied to a DLL.)

Rewired was designed around the capabilities and functioning of Unity 4.3 - 2017.1. These changes are fairly major and it's simply just not going to work without significant changes to Rewired's editor system to workaround all the new structural requirements of this new Unity system. I do not know at this point whether this is even possible to do while keeping the robust automatic editor script management of files. I have not done any work with this new system yet. It is likely I will have to release a new version of Rewired specifically for Unity 2017.3 that includes all the changes required and maintain that as a separate Unity project.

 

Certainly no offense was intended. And yes, I know you can move it around between different folders -- but as you noted here and on your website, you can't move the elements from within the folder.

Got it. Well, it seems to work except for the errors that it throws during recompile, to be honest. In the end I didn't even have to move it permanently, I just moved it out of the folder and back in. That may have even been unnecessary, or a temporary bug in the current version of unity.

I'm sorry, but this doesn't match my experience at all. I've been using Unity since 2.6, and there used to be some problems with at variety of import issues when they first added the asset store. But I have seen things matching based mainly on filename since 5.6 or so. Even better, when the filename is matched for some elements in a package, and new files are added to that same package, then it puts them in the relative location that it discovered.

For instance when you added a new controller mapping, it knew right where to put it even though I'd moved the folder. There are some exceptions, such as if I were to not import an entire folder like Examples and then later try to do so, but that's easily fixed by hand when it arises. I'm sure that with enough customers on a variety of builds, you run into people with problems all the time; my experience with assets, of which I have a few hundred, is that they update properly in 5.5, 5.6, 2017.1, and 2017.3.

Okay, I see. So this is mainly based around adding in integrations...? Or is there something else that it's handling that I should be aware of? On windows this seems to be working fine with XInput and so forth just like usual. It's just the errors in the editor that keep popping up. I haven't tested this on other OSes yet.

If you're having to do reflection into Assembly-CSharp, how about simply also giving another assembly name that it looks for if it doesn't find what it needs in there? Such as, if someone wants to include Rewired in an asmdef file, you just say "it has to be called RewiredGameAssembly" or somesuch? Then we make an asmdef with the name RewiredGameAssembly, and things should "just work" even in the new architecture, I think?

10-4. I sent you an email separately about this. I'm off for the rest of this week for the Thanksgiving holiday here in the US, but if you'd like to use me as a guinea pig for 2017.3 beta compatibility, I'd be happy to be a part of that. It won't be my first rodeo doing that with an asset store author for a new unity build.

At any rate, I think that potentially you can make a really simple change to just say "if it's not Assembly-CSharp.dll, then it must be called [X].dll" where you tell us what [X] is. Then all your reflection and integration work should function just fine. I suppose that with UnityEditorBridge being somewhere else, you might need us to create two asmdef files -- which, for an asset that is as central as input, isn't a crisis. We'd have one root [X].asmdef file in the Rewired base folder, and then an [X].Editor.asmdef file that we create in the Rewired/Editor folder. No assemblies or other files of yours would have to be moved, making everything else moot, and you wouldn't need to fork your code.

Feel free to email me, though. I'll probably be working some on Sunday, or else I'll definitely be back around Monday. I honestly think we might be able to work this out more simply than you're expecting, since reflection tends to be pretty forgiving (telling you if something doesn't exist versus just dying).

 

None taken.

You can move every single file except Rewired_Core.dll and the zip files in the Rewired/Internal/Assets/ folder, but the zip files wouldn't cause a problem until you actually tried to install one of those optional assets from the menu.

This was a very major problem when Unity 5.x was released and the cause of many, many support emails. It is possible they reverted this at some point during the 5.x lifetime. I will have to test again.

The errors are strictly related to the editor code (Rewired_Editor.dll). None of this information is used or exists in the runtime. (File paths don't even exist in builds, nor do any of the editor scripts.)

Thanks for the suggestion. I haven't worked with this system before so I am not familiar with how it works or its requirements. I will be determining what / how to achieve the desired results when I start looking into this.

I did see the email, but haven't gotten to answer it yet. For some reason, there has been a significantly higher number of support emails in the last 2 days, so it takes some time to get through them.

Thanks! This should likely be straightforward enough for me to work out the proper workflow once I get up to speed on the system.

There may be other ways around it such as using other means to detect the information I need. I'd like to keep things as simple as possible, not requiring any special instructions.

Will do, but I probably won't be able to get to this issue immediately.

It really just depends on what I can no longer do/rely on, whether there's another way to achieve the same result, and if there isn't, what has to be removed in order for it to work.

 

@guavaman: Glad no offense was taken, and that all makes good sense.

It's actually interesting that you bring up wanting a way to work around having a specific dll reference, because I bet what you could do is simply have it look at all the loaded assemblies and see which one has your class in it: https://docs.unity3d.com/2017.3/Doc...lation.CompilationPipeline.GetAssemblies.html

That class was just suggested to me higher in this thread by the unity engineer for something else, and I think it's backwards compatible with all the unity versions you'd be supporting.

As someone already on the newer version of unity, and who isn't actively using the editor-based parts of Rewired right now, is there a dll or script file that I can ditch to make it stop giving me those errors? I also kind of wonder if that adds to the after-compile time every time the code is loaded in the editor -- avoiding that hit would be nice, if possible.

edit: By the way, on the issues with importing during early 5.x, it might have been something they since fixed, yes. Which would explain why I didn't see it. I saw the chaos that was the early 5.x cycle, and remembered the pain of the early 4.x cycle, so we stayed on something like 4.4 for a looong time. Then when we upgraded we went straight to 5.4 or 5.5, I can't recall which. So that might explain why I never saw the issues you were mentioning.

 

[/QUOTE]
By design the .asmdef system does not take the magic folders into account. You will need to add a .asmdef file to editor folder manually and set the platform to Editor only.[/QUOTE]

Make it allow to have few .asmdef for one Assembly so we can add it into every Editor Folder under one extension and build all scripts into one EditorAssembly

 

@x4000 That point about VS reloads,was it about the actual reload taking place as an overhead or about the prompt VS pops up every time a change has happened to a solution/project structure?

 

Thanks for the bug reports. Both bugs are the same issue, editor only assemblies not being referenced correctly in .asmdef files. The issue has been fixed.

 

The actual reload taking place, not the prompt. After you agree to ghetto prompt, which you must if you add any files, it unloads the solution and every project, then reloads them all. It then reopens any files you had open.

It's pretty darn fast, but I've noticed that there is a pretty linear time increase from 3 projects in a solution to 9. Having 40+, or whatever other high number, would likely be untenable.

 

Awesome, thank you!

 

Ok. Asked because 2-3 days ago I watched some of the latest Microsoft videos and there is one with Jb Evain which mentions the prompt is removed for 15.5?! I think.

 

Is that VS 2015 with a service pack, or is that VS 2017 with one? Right now I've got both installed, but I'm using VS 2015 since it was set up the way I wanted and has a better feel to it. Took me long enough to get used to that after using VS 2008 for almost a decade. I started with the original VS.NET when C# 1.0 came out, and it was hard to transition out of that era for a while, in terms of IDEs.

 

2017. Here's the link.

 

I've been playing around with this yesterday, i'd love to make a custom editor for this. However i'm unable to draw the assembly definition file editor, nor is the type available to create a new asset.

Why is the assembly type defined in EditorInternal? Problems like Editor folders can totally be solved with some editor scripting, but its quite hard to do at the moment.

 

Yes, I am aware of other ways to get the assemblies through reflection (though I didn't know about this Unity method), but I wanted to avoid that because of the increase in processing time. And the CompilationPipeline class was added in 2017.3, so that will not work.

The pure .NET way to do it would be this:

Code (csharp):

1. foreach (Assembly a in AppDomain.CurrentDomain.GetAssemblies()) {
2.    foreach (Type t in a.GetTypes())  {
3.        // ... do something
4.    }
5. }

This is what I will have to do.

I don't think so. The biggest impact on compilation time is the serialized controller data. See this for more information.

The only way is to delete Rewired_Editor.dll. But the error logging is not causing any harm. It's not throwing an exception. It's logging it as an error using Debug.LogError.

 

I have confirmed by downloading and installing each Unity 5.x version and testing that this intentional change (it wasn't a bug -- I remember the initial change being announced in the Asset Store newsgroup at the time) was reverted in Unity 5.3. This is also in the release notes, though it's not obvious the exact effect it had:

https://unity3d.com/unity/whats-new/unity-5.3

• Asset Store package import improvements were disabled, as they caused certain package updates to delete more than expected.

I will update my documentation with this information.

 

Fantastic! Thanks for the link on that. It will be interesting to see if it's able to intelligently just reload projects that are changed, or if it will reload the entire solution every time. Either way, it will likely be done by the time I finish alt-tabbing over there.

Ah, that is fantastic! Nice to know that what I saw was matching the wider reality, and why. And hopefully makes ongoing support easier for you, since I imagine most people migrate to 5.6 instead of staying on 5.0 to 5.3. Too many bugs in those earlier ones.

 

I have a plugin folder like this

With that .asmdef, the script complains that they could not find the dll that is included right after them. But however if I move the Plugins folder out of Editor like this

Now it works. Why? Because in the doc



This suggests that .asmdef will always be able to depends on any precompiled assemblies. Also I thought any magic folder inside the reach of .asmdef would have no meaning anymore so why moving it out of Editor results in a compilation? (It probably related to the "Editor" setting of those dll, but could someone explain the reason?)

Also with the first scheme, adding an another .asmdef for the dll with only "Editor" would work

While if I use "Any Platform" it wouldn't work

I thought Any Platform is supposed to include Editor too so why I have to set it to Editor specifically?

On an another note I have a feature request. If you could add a button to turn on/off the asmdef it would be great for plugin developer. That way I could setup the asmdef and bundle but without activating it yet making it optional. Currently even if I uncheck Any Platform and also Deselect All, it would still have an effect of "include everything into this assembly, but no one will be able to use it" and the referencing scripts will complain. The only way to disable is to delete the asmdef file itself at the moment and because of that I am hesitating to include the asmdef.

 

I'd expect it to be intelligent for one reason only. One of the features that VS2017 highlights is Lightweight Solution Load which ,basically, loads only selected(manually and historically tracked) projects , so , and this is just a guess, there is a mechanism to selectively do something to the projects in a solution. It stands to reason that you can also reload it. Now it depends on how much of this mechanism is exposed to plugins like VSTU but I'd like to think that since they are endorsed by MS and since this video is part of the marketing for VS, they do expose it. I do hope it's not a straight up hack that bypasses the prompt.

 

@5argon: That's a bug that they have fixed, presumably for b11. So it should work as you expect after that patch comes out.

@npatch: Apparently I need to start following VS news, because those are really useful developments. Thanks for the added info! I hope it's not just a simple hack of a workaround, too. Is there a newsletter or similar that talks about the release dates for these new features? I'm unclear which features are in VS 2017 or VSTU.

 

Either the MS blog or the MS youtube channel. Twitter is another good source.

 

I've been experimenting with the new ASMDEF system and considering issues with making Rewired compatible with it. I thought you might be interested why making a complex package like Rewired compatible with the new ASMDEF is not necessarily a straightforward process.

Here's a list of all the optional addon packages included in Rewired (or as an additional addon) that are managed by the automated installer/upgrader:

Extras:
Control Mapper
Touch Controls
Unity Input Override

Integrations:
Behavior Designer
Corgi Engine
Play Maker
Rex Engine
UFPS
UFS
Ultimate Survival
UnityUI

Other:
Documentation

Platform / Library packs (DLLs, not scripts):
Windows 8 Store
Windows 10 UWP .NET
Windows 10 UWP IL2CPP
Windows SDL2
OSX SDL2
Linux SDL2

Plugins:
Nintendo Switch Plugin

These addons are all distributed as Zip files.

When installing any of these addons, they are extracted into a sub-folder inside the root Rewired folder (wherever that may be in the project) based on type. When Rewired is updated, it does an automated check to see what has been installed and updates any addons that are detected. This is done by unzipping the file to the same install location based on the detected root folder of Rewired. Changed files are overwritten as needed.

Many of these addon packs have editor scripts. They they are stored as single zip files. The ASMDEF system requires that the editor scripts be separated from non-editor scripts, which means simply extracting the zip file over the existing files will no longer work. This change means 1) a single Zip file for each addon pack is no longer adequate because editor files need to be separate from non-editor 2) Zip files are no longer adequate because they have no means of tracking a file by GUID which would be required to find a file that the user has moved to some arbitrary location.

You can see from the above that separating all these scripts into ASMDEF folders will completely break this installation and upgrade process.

An elaborate workaround might be possible by extracting the zip files to a temp location, examining .meta files, searching the AssetDatabase for the GUID extracted from the .meta, and overwriting the file in that location. (Essentially, making my own Unitypackage system.) However, this becomes far more complicated when taking into account adding newly added files to an installed package and deleting now-non-existant files from an installed package during an upgrade.

There is no easy solution to these issues that I can see. At this point, I am considering 2 possible options:

1) Add documentation discouraging users from breaking Rewired up into ASMDEF folders. There are only a handful of scripts included with Rewired which do not add up to much compile time. The vast majority of Rewired is already a DLL. If they choose to move the files, upgrades of addons cannot be handled automatically. They will have to manually open each Zip file and extract the files over the files they've moved into ASMDEF folders.

2) Release and maintain a completely separate branch of Rewired for Unity 2017.3 that already has everything separated into ASMDEF folders somewhere under the Rewired folder. Create and maintain new versions of all addons that separate editor and non-editor scripts so they can be extracted into the appropriate ASMDEF folder based on type. This is the cleanest option, but adds a lot of maintenance issues, especially when making changes to addons. This will bring the total number of maintained branches to 4.

The fact that Rewired has an automated installer / upgrader to make things easy and automatic for the user is the very reason it seems inflexible and has problems when certain parts of its file structure are arbitrarily modified.

As for the issue of finding the root Rewired folder in the first place, if I can't rely on the Rewired_Core.dll being left in place, the only real solution I can come up with is adding a blank .bytes file with a known GUID to the root folder so I will be able to use that GUID to find it using the AssetDatabase. Of course, one could also decide to delete or move that file...

 

Is there anything obviously negative about having a bunch of separate ASMDEFs? For example:

Code (csharp):

1. My Folder
2. |-- Examples
3.     |-- Scripts
4.          |-- Runtime
5.              |-- ExamplesRuntime ASMDEF
6.              |-- Some scripts...
7.          |-- Editor
8.              |-- ExamplesEditor ASMDEF
9.              |-- Some scripts...
10. |-- Extras
11.      |-- Some more ASMDEFs
12. |-- Plugins
13.      |-- Even more ASMDEFs
14. |-- Etc
15.      |-- Even more ASMDEFs

This may lead to 10-20 separate DLLs being created for one package.

For Rewired, this would mean each addon installed would have its own ASMDEF. This might simplify things some.

 

bug: 972818 project sync not working when renaming a script file in the editor then renaming the class in monodev.

 

Got a confirmation from Jb. "It will only reload the project that has been modified, not the entire solution.".
Guessing this is only going to be available for VS2017+.

 

@x4000

I believe I have found an acceptable pattern for using .asmdef's in Rewired:

EDIT: I have backtracked on this approach and do not recommend it to asset developers. See this post for the reasoning.

Under the root Rewired folder:
|-- Rewired_CSharp.asmdef

This .asmdef file will compile all C# scripts under the Rewired folder into Rewired_CSharp.dll

Under Rewired/Internal/Scripts/Editor:
|-- Rewired_CSharp_Editor.asmdef

This .asmdef file will compile the default editor C# scripts to Rewired_CSharp_Editor.dll.

(Currently the editor DLL reference bug affects this, but I found a way around it to test and it seems fine.)

Every addon pack that includes editor scripts will have an additional Rewired_PACKNAME_CSharp_Editor.asmdef file added to the Editor folder which references Rewired_CSharp.asmdef and Rewired_CSharp_Editor.asmdef.

The most important issue here is that the .asmdef file (and its accompanying .meta file generated in Unity 2017.3) doesn't appear to cause any errors or weird exceptions in Unity 4, 5, or 2017.1. This makes it safe to just include the .asmdef files in the addon packs without having to maintain separate versions for Unity 2017.3.

The other thing is that the .asmdef files can be nested with the closest one being used, so all Editor folders can have their own .asmdef overriding the root Rewired_CSharp.asmdef. This means the final build will have only one additional DLL: Rewired_CSharp.dll, while the editor may have many additional DLLs (one for each addon).

So far it looks to be working, but I do need to do some more testing in all versions to make sure everything works correctly in the editor and builds before I release an update. With .asmdef files being implemented out of the box, there is no need for the user to move files around manually, thereby eliminating all the issues involved there.

This pattern might work well for most existing asset store assets.

 

@guavaman Did you do any testing on how much overhead the extra assemblies add?
I converted a project to use a similar structure to what you described and noticed that it added significant overhead, compared to putting it all in just two assemblies (Vendor and Vendor/Editor, in my case).

Another issue I found with too many assemblies is that it polluted the project view in Visual Studio or Rider. At least Visual Studio has Unity tools that alleviates.

The drawback is having to move stuff manually over and possibly breaking packages that have a hard dependency on directory structure.

 

@guavaman: That's fantastic news, and that pattern should work well, yes. I think that for a lot of asset store packages that are simpler and don't have so many plugins and moving parts, they can have their asmdefs violated and changed... but in the case of yours, that would be highly discouraged, of course.

I'd love to have a beta build of that if you'd like some extra help testing. I sent you an email a bit ago with my invoice number and such; chrispark7 at gmail was the contact info.

@npatch: Thanks for the heads up on those locations, I'll take a look!

@SugoiDev: I haven't seen any noticeable degradation in performance with 20ish dlls in a project. The main thing is solution reload time. But compile time is faaaast. The main thing is if you wind up accidentally triggering a cascade of unexpected compilations, so it might seem unexpectedly slow if you wind up with that issue. Right now it's just intuition and looking at your project based on knowledge of the documentation that can diagnose that problem; it doesn't tell you what just got compiled that I'm aware of.

@lukaszunity: Was the fix to the editor folders pushed as part of b11, or is that further out? There was also a seemingly-missing fix to the frustrum matrix being wrong on dynamic objects with dynamic occlusion turned off on them. The fix was noted as complete, but then not in the release notes for b11. Do you guys queue up two betas at a time, and those sorts of things were slated for b12? Just wondering.

 

I haven't because I wouldn't expect a significant performance overhead. How did you measure the overhead in your project? Is this runtime performance or something else?

That's actually a very good point and something I had not thought of. This will definitely be an issue with all the editor assemblies.

 

Okay, I sent you an email with a link where you can download it.

That's good to know you haven't seen any noticeable performance degradation. But that's also a good point about triggering unexpected compilations. Have you tried switching build platforms with that many assemblies in the project? It will have to compile all of the build assemblies in that case.