Example Project - Assembly Definition Files

Hi

Why Assembly Definition info is stored in separate not Unity object text(json) files instead of folder meta files and editor support on it?

Even if this is necessary to have separate file why not use ScriptableObject with exact structure, correct Editor In Inspector and easy script access?

 

Opening any of the scripts in Visual Studio Community 2017 results in an error for each of the generated assemblies, with them missing afterwards in the Solution Explorer. Shouldn't they be suffixed with the assembly name, such AssemblyDefinitions_ExampleProject.Folder0?

 

This actually prevents to test this feature at all.

Any idea when the update will be available for VSTU?

 

I love this new feature a lot. I have successfully created assemblies with Visual Studio 2015, but I am asking myself, will there be also a Visual Studio CSharp Project available? I would like to split parts of my application into different assemblies and c# projects by using this feature. Like Unity does with Editor and Plugins today.

Keep up the good work!

 

Hello folks,

Jb from the VSTU team here. In the meantime, we're making non supported beta builds available for those of you who want to try this feature:

• For Visual Studio 2015
• For Visual Studio 2017

For 2015, just close all Visual Studio instances and install the .msi. You can always revert to the last stable version.
For 2017, you'll need to install the .msi, and also to install the .vsix in your Visual Studio 2017 instance.

Let us know if you have any issue.

 

I'm using VS2012 and it works quite fine. Anything I need to know though?

 

Works perfectly, but how do I reference the default script assembly? Using "ProjectName", "ProjectName-CSharp" or "Assembly-CSharp" doesn't seem to work.

This is needed for imported scripts from the Asset Store that use the Editor folder, which gets overriden by custom assemblies.

 

I think @TFlippy is talking about something I was also mentioning here.

It's about assetstore packages. If I want to commit an editor tool to the AS and my tool is referencing the UnityEditor.dll, how will that work out if the user, who is downloading my package is using a different version of the UnityEditor.dll?

 

I'm currently using FullInspector from the Asset Store for its inspector extensions, which utilizes several attributes to determine how the objects are serialized or appear in the inspector. But since I moved it in its own assembly in order to be able to use those, the "Editor" folder inside the addon gets ignored and compiles unconditionally when building the game (which results in an error, as it can't include Editor-related stuff).

Would have it been possible to add a way to have them conditionally compiled / ignored similiar to the way the Editor folder works?

 

@TFlippy Try moving the Editor scripts from FullInspector in a new folder under Assets\Editor and set a different assembly for that(e.g. FullInspector-Editor).

That should do it.

 

Any idea if this works / will work with JetBrains Rider?

 

What's the workflow when we add, remove or rename a script?

 

It works, I was testing it yesterday.
There were minor issue for the case, when Assembly Definition name contain sln name.
Fix was done https://github.com/JetBrains/resharper-unity/commit/aa422b7ca1db2950e4b67abe3bfb00ae9e81041e, but it might not get to the current release. So for now, avoid sln name in Assembly Definition name, which I suppose is a rear case anyway.

 

I have a one improvement request.

Currently, the generated csproj lists files using full path from the root of the Assets directory. So if we have an assembly in following structure:

Assets / Code / Assembly1 / Assembly1.assembly.json
Assets / Code / Assembly1 / Script1.cs
Assets / Code / Assembly1 / Utils /Script2.cs

Both project would contains "Assembly / Code / Assembly1" folders until they actually start showing script files relevant to our assembly. So it would be:

Assets -> Code -> Assembly1 -> Script1.cs
Assets -> Code -> Assembly1 -> Utils -> Script2.cs

Since we are only presented in files at or below the level, where assembly definition file is located, would it be possible to display the files in relation to where assembly file is located, instead of in relation to the root of Assets folder?

In the example I would expect that the project would contain files like this:

Script1.cs
Utils -> Script2.cs

I think this is probably more a request to VSTU, not unity. However, it would make some external tools, like Resharper work way better in respect to the namespaces, most probably we do not want to have "Assets.Code.Assembly1" in our namespace.

 

Gotcha, so what you've decided to implement is an extension to the already existing folder structure where Plugins and StandardAssets have their own .dll
It's not bad but why didn't you chose namespaces as a split boundary? I mean if you look at who knows about interdependencies, it's not the level designer, not the animator or anyone else that has the ability to move files around the project, it's the programmer, so why not bind assembly definition to the code itself? That was hinted a few years back by Lucas and made so much sense from my end that I started using namespace

 

I think you misunderstand. Assembly Definition Files don't define projects. It defines whether some subfolders of Assets will get compiled into a different assembly or whether they'll get compiled into the main assembly.
The project at the end will still be one and it will contain all the scripts , like before.

 

That's why I mentioned this request is more targeted to VSTU, since it's the addon which generates the project files according to assembly files definition, as far as I understand.

 

I'm not sure that's the case. As far as I understand, Unity will only rebuild assemblies that have been changed. That's the actual point of this, if you have a big part of your code that rarely gets changed, you put it in a separate assembly, and so it won't get recompiled when you change one of your other scripts.

 

There won't be any projects generated. You will only have the one project for all of Assets.
Say you have two folders.
Assets/MyAssemblyScripts1
Assets/MyAssemblyScripts2

You have only created Assets/MyAssemblyScripts1.assembly.json.
So Unity now knows whenever it recompiles the assemblies that ALL scripts under Assets/MyAssemblyScripts1 will go into <assembly_name_given_in_assembly.json>.dll.
But since you haven't created an assembly.json file for MyAssemblyScripts2 folder then ALL the scripts under it will go into the regular Assembly-CSharp that all code compiled into before.

You still have only one project which is <ProjectName>.csproj

The plus side is that when Unity recompiles due to a change, it will check if the change happened in a script that's under MyAssemblyScripts1 folder or not. If it did, Unity will only recompile the MyAssemblyScripts1.dll but not the Assembly-CSharp.dll. If the change happened in a script under the MyAssemblyScripts2 folder, then there's no reason to recompile any script under the MyAssemblyScripts1 folder. It will recompile though, ALL scripts that falls under the Assembly-CSharp assembly,including all scripts in the MyAssemblyScripts2 folder.

At this point there's no real need for a different project. If you want to isolate code tracking in versioning systems, just have MyAssemblyScripts1 be its own repository(Nested under any projects that will need it).
If you need to redistribute the dll, just grab the dll that gets compiled and use it in the Plugins folder of another project. Personally though, I like the idea of having the code of the "library". You can easily do changes without all the MSBuild hackery and ProjectFileHook stuff to rebuild the project and also copy/move the resulting assembly in an appropriate folder under Plugins to update the library being used in the core Unity project.

Another upside is that, before, if you wanted to have a cs library project which provided MonoBehaviours and you had also created CustomEditors for them, you needed to also have an extra cs library project for the Editor scripts. Something people from Unity told me several months ago. Now this is as easy as bundling all Editor scripts for the "library" in a folder and add a <folder_name>.assembly.json file to it. Presto.

Is there any other reason to use normal CS Projects at this point? I can't think of any.

 

Hmm...I read the link above but it said nothing about creating separate csproj files as a result. Just said it would separate the project scripts into different dlls. Ok then my bad.
@rastlin Seems like I misunderstood afteralll. Sorry about that. For what it's worth, after reading the lukasz' comment, I tried the generation with MonoDevelop(can't change VSTU now..) and there the generation only keeps the assembly folder as the root in the generated project.

 

VSTU does generate csproj file for each assembly definition file.

Currently the generated folder structure in the project looks like this:


In my opinion Assets->Assets->Scripts->FolderX structure is redundant, it could be cleaner if it could look like this:


I spend 80% of my time in IDE, chance I'm, more interested in how this feature interacts with IDE rather than Unity itself. In my current workflow I'm using in 2017.1 I have exactly the same structure as the definition file provides, I'm just building my assemblies independently in IDE and copying them to Assets folder for Unity to reimport.

 

Do you have an extra Assets folder inside the root Assets folder? Or is this a bug in VSTU?

I wonder if there's a reason for the folder structure present though.Even the previously generated Editor project kept the same Assets root folder in it and based all scripts as relative to Assets instead of Editor.

 

Yes, it's from example project, it has a duplicated "Assets" folder in it, it's not a bug.

 

Is it possible to use assembly definition files when the C# code has conditional compilation? Specifically I'm trying to wrap FlowCanvas from the asset store in a flowcanvas.runtime.assembly.json. But, some code is wrapped in #if UNITY_EDITOR. Not picking on FlowCanvas, its just a good example. Is code not suitable for assembly definition files if it contains conditional editor-specific compilation? I know about includePlatform:["editor"] but in this case, the files are not editor files.

 

EDIT: I misread something in this thread, and after revisiting the feature document, I noticed that dependencies, aka references are defined manually, so all good! You can ignore the below

We are currently using our own separate solution with multiple assemblies, together with a solution post-processor that injects the projects from that solution into the generated solution. Great to see that we should be able to get rid of this build customisation, as it periodically causes some issues!

One thing I'm concerned about though, is that the dependencies between assemblies are automatically deduced. I would much rather define them explicitly. I see this causing two kinds of issues when you accidentally reference something from another assembly. This can cause two kinds of issues:
1. It might break the design principles without being warned, causing just generally bad spaghetti code
2. You might later run into hard to fix cyclic dependencies, as you didn't pay attention to dependencies properly from the start.

I would much rather define dependencies manually, than have them automatically added!

 

Code in those assemblies cannot call code from Assembly-CSharp_resident code, so there's no cyclic dependency thing. Unless you mean between the other assemblies.

 

Totally agree with rastlin about the project structure: it would be much more readable and easier to navigate by removing the redundant folders and only include folders from the json file level and beyond.

Also, even the compilation time will scale better with this new structure, I notice it still takes 2-3 seconds to recompile even a small project with a few classes. Compiling the same project in VS only takes a fraction of a second. My understanding is that Unity also unload/reload the editor GUI and the game assets when recompiling, but is there any plan to improve the compile time further?

Thanks and good job Unity team.

 

When bringing TextMeshPro (the purchased source code version for 2017) into a clean project and using the assembly file, it throws an error in a bunch of files: "The type of namespace name 'UI' does not exist in the namespace 'UnityEditor'. Are you missing an assembly reference?". Any idea why this would happen? It works fine without the X.assembly.json file ... but the moment one is added to the project, it breaks as above.

Edit: It has nothing to do with TMP. Create any new project. Add an editor folder, and an editor file with a "using UnityEditor.UI" line. This works fine. Then add an assembly.json file. As soon as its added, the above error is thrown.

 

If I add the UnityEditor.UI.dll to the project it fixes itself. I'm assuming this should be fixed internally.

 

Am I correct in understanding that if a project has 2 base folders (A and B), and only B has an assembly.json, then changing a file in A will not re-compile B (since B is essentially a seperate .dll), but changing a file in B will re-compile A (since A is still part of the generic non-assembly code)?

 

Shouldn't. Folders and scripts that are not part of an assembly.json will eventually be compiled in Assebly-CSharp.dll.
So if you change something in B then only B should recompile. If you change sometihng in A only the scripts under Assembly-CSharp should. Doesn't really make sense to say it improves compile times otherwise.

 

From https://drive.google.com/file/d/0Bykxs2qcd6PSUTJhYkJySS1hazA/view

"If a project is using .assembly.json files, it is highly recommend that they be used for all scripts
in the project. Otherwise the scripts not using .assembly.json files would always be recompiled if
any .assembly.json file is recompiled. And thereby reducing the benefit of using .assembly.json
files."

This is why I want a confirmation of this. I am trying to retrofit this onto something already built and its not so easy (my fault, it wasn't built in a way friendly to this), and I don't want to jump through any more hoops before I know for sure how this is working.

 

In that case, the whole project structure has to change to reap the benefits. I get that if signatures are changing or stuff are added that callers from the main assembly will force a recompile to the main assembly too, but if it's a transparent change why should it?

 

And how will the compiler know if it's a transparent change?

It cannot, unless it compiles the main assembly. You are also doing it inside your head as well, when you make a change, you are scanning your dependant code and only after you do that, you know that "it's a transparent change" or not.

It has always been like this in any compiler, once you change something down the dependency tree, you have to recompile everything up the tree - just in case the change downstream affects the upstream.

 

But the API hasn't changed in a transparent change. The symbol tree should be the same at least up to the function signatures. If you change something that's ultimately in an inner scope but doesn't change the function signature which is what you end up calling in other assemblies why should it force the other assemblies to recompile? I'd understand relinking , since the byte offsets of the functions inside the library change due to a content change but not recompiling?
Am I missing something?

 

@jbevain
Updated VSTU's from this post don't work with Unity 5.5

 

That's not unexpected, the beta build provided above is just for 2017.2 betas.

Thanks for reporting it that being said

 

By the way.
MSDN reports that VSTU is already released in the future

Has anyone been there (in the future), is it really released on August 14?

 

In case someone has installed the new 3.3 version of VSTU 2015 and realized, that it's broken and doesn't work and can't revert, because the latest stable is now the broken one, can get the old 3.1 one here: https://www.dropbox.com/s/yrsixrtthxgvxxv/vstu2015.msi?dl=0

 

How do I manually specify an assembly? I used UnityEditor.Graphs in my code, but the generated .csproj was not included and I tried to specify it in the reference array and could not work

 

What happens if you have multiple identical Assembly Definition files in different folders?
What happens if you have multiple Assembly Definition files in the same folder?