В предыдущих версиях Unity скрипты собирались в единую сборку Assembly-CSharp.dll.
И при добавлении новых скриптов увеличивалось время компиляции. Теперь в новой версии появилась возможность определять собственные управляемые сборки, основанные на скриптах внутри папки, что существенно сокращает время компиляции, особенно в больших проектах. Теперь можно думать о каждой управляемой сборке как о единой библиотеке в проекте Unity.
На рисунке выше показано, как вы можете разделить сценарии проекта на несколько сборок. Если вы только изменяете скрипты в Main.dll, ни одну из других сборок не потребуется перекомпилировать. Поскольку Main.dll содержит меньше скриптов, он также компилируется быстрее, чем Assembly-CSharp.dll.
Аналогичным образом, изменения скриптов, которые вы делаете в Stuff.dll, будут приводить только к перекомпиляции файлов Main.dll и Stuff.dll.
Файлы определения сборки — это asset файлы, созданные вами, перейдя в Assets > Create > Assembly Definition. Это файл с расширением .asmdef.
Примечание. Имя папки, в которой находится файл определения сборки, и имя файла файла определения сборки не влияют на имя сборки.
Пример:
Создадим папку Scripts. А ней папки Locomotion, Editor, Utils. В папке Locomotion еще две папки Normal и Anvanced. Теперь создаем скрипты
Utils > MoveExtension.cs
Locomotion > Anvanced > AdvJump.cs
Locomotion > Anvanced > AdvMoveForward.cs
Locomotion > Normal > Jump.cs MoveForward
Locomotion > Normal > MoveForward.cs
Locomotion > LookForward.cs
Editor > MoveForwardEditor.cs
И скрипте MoveForwardEditor определим немного кода, чтобы нужна была ссылка на MoveForward.
Теперь чтобы нам создать управляемы сборки нужно в папке со скриптами создать .asmdef файлы. Причем если этот файл лежит в папке допустим Locomotion, то в файл сборки подхватит и скрипты из папок Advanced и Normal, если в этих папках не определены свои файлы сборки.
В папке Utils создаем сборку UtilityAsm.asmdef
В папке Locomotion создаем файл сборки LocomotionAsm.asmdef
В папке Locomotion > Anvanced > LocomotionAdvancedAsm.asmdef
В папке Editor EditorAsm.asmdef
В папке Locomotion > Normal ничего не создаем, т.к. скрипты из этой папки попадут в сборку LocomotionAsm
И тут мы получаем ошибку…
Assets/Scripts/Editor/MoveForwardEditor.cs(3,22): error CS0246: The type or namespace name `MoveForward' could not be found. Are you missing an assembly reference?
Скрипт MoveForwardEditor ругается, что не может найти ссылку на MoveForward. Все правильно в данном случае MoveForward оказался в другой сборке и не доступен. Что бы это исправить нужно сделать следующее
1. Выбрать файл сборки EditorAsm
2. Нажать на +
3. Выбрать файл сборки LocomotionAsm, потому что MoveForward именно там.
4. Из платформ оставить только Editor
5. нажать Apply
Теперь ошибка ушла. И давайте посмотрим в папку Library и увидим наши сборки.
После сборки проекта мы также увидим эти сборки, кроме EditorAsm, т.к. это скрипт эдитора.
Есть еще одна Важное замечание. Файлы сборки не поддерживают директивы препроцессора, т.к. всегда статичны.
Статья была написана как попытка перевести официальный блог ) Всем спасибо за прочтение статьи. Жду ваших комментариев.
И при добавлении новых скриптов увеличивалось время компиляции. Теперь в новой версии появилась возможность определять собственные управляемые сборки, основанные на скриптах внутри папки, что существенно сокращает время компиляции, особенно в больших проектах. Теперь можно думать о каждой управляемой сборке как о единой библиотеке в проекте Unity.
На рисунке выше показано, как вы можете разделить сценарии проекта на несколько сборок. Если вы только изменяете скрипты в Main.dll, ни одну из других сборок не потребуется перекомпилировать. Поскольку Main.dll содержит меньше скриптов, он также компилируется быстрее, чем Assembly-CSharp.dll.
Аналогичным образом, изменения скриптов, которые вы делаете в Stuff.dll, будут приводить только к перекомпиляции файлов Main.dll и Stuff.dll.
Как использовать файлы определения сборки
Файлы определения сборки — это asset файлы, созданные вами, перейдя в Assets > Create > Assembly Definition. Это файл с расширением .asmdef.
Примечание. Имя папки, в которой находится файл определения сборки, и имя файла файла определения сборки не влияют на имя сборки.
Пример:
Создадим папку Scripts. А ней папки Locomotion, Editor, Utils. В папке Locomotion еще две папки Normal и Anvanced. Теперь создаем скрипты
Utils > MoveExtension.cs
Locomotion > Anvanced > AdvJump.cs
Locomotion > Anvanced > AdvMoveForward.cs
Locomotion > Normal > Jump.cs MoveForward
Locomotion > Normal > MoveForward.cs
Locomotion > LookForward.cs
Editor > MoveForwardEditor.cs
И скрипте MoveForwardEditor определим немного кода, чтобы нужна была ссылка на MoveForward.
using UnityEditor;
[CustomEditor(typeof(MoveForward))]
public class MoveForwardEditor : Editor
{
}
Теперь чтобы нам создать управляемы сборки нужно в папке со скриптами создать .asmdef файлы. Причем если этот файл лежит в папке допустим Locomotion, то в файл сборки подхватит и скрипты из папок Advanced и Normal, если в этих папках не определены свои файлы сборки.
В папке Utils создаем сборку UtilityAsm.asmdef
В папке Locomotion создаем файл сборки LocomotionAsm.asmdef
В папке Locomotion > Anvanced > LocomotionAdvancedAsm.asmdef
В папке Editor EditorAsm.asmdef
В папке Locomotion > Normal ничего не создаем, т.к. скрипты из этой папки попадут в сборку LocomotionAsm
И тут мы получаем ошибку…
Assets/Scripts/Editor/MoveForwardEditor.cs(3,22): error CS0246: The type or namespace name `MoveForward' could not be found. Are you missing an assembly reference?
Скрипт MoveForwardEditor ругается, что не может найти ссылку на MoveForward. Все правильно в данном случае MoveForward оказался в другой сборке и не доступен. Что бы это исправить нужно сделать следующее
1. Выбрать файл сборки EditorAsm
2. Нажать на +
3. Выбрать файл сборки LocomotionAsm, потому что MoveForward именно там.
4. Из платформ оставить только Editor
5. нажать Apply
Теперь ошибка ушла. И давайте посмотрим в папку Library и увидим наши сборки.
После сборки проекта мы также увидим эти сборки, кроме EditorAsm, т.к. это скрипт эдитора.
Есть еще одна Важное замечание. Файлы сборки не поддерживают директивы препроцессора, т.к. всегда статичны.
Статья была написана как попытка перевести официальный блог ) Всем спасибо за прочтение статьи. Жду ваших комментариев.
Комментарии (10)
CrazyFizik
20.01.2018 15:00Круто. В 2017 году авторы юнити узнали про существование раздельной компиляции… и все равно сделали это через одно место.
mmortall
23.01.2018 21:21Вот это реально круто и удобно. До этого приходилось вручную делать отдельные проекты и собирать dll библиотеки. Теперь будет напорядок проще.
AxisPod
По мне так слегка не в ту сторону пошло развитие. По мне так дали бы возможность создавать дополнительные .net проекты, глядишь без шаманства можно было бы использовать разные языки, к примеру F#, на нём всё же ИИ приятнее писать.
yatagarasu
Руками можно давно (и подозреваю что всегда). Кидаете сборки в ассеты и вперёд.
Можно создать свой солюшен в корне где держать все юнитивские и дополнительные проекты.
Не особо большое шаманство и всяко удобнее чем сделали бы в юнити.
CrazyFizik
Xenko Game Engine — там на выходе обычный .NET solution
AxisPod
Вы про то недоразумение, за что хотят очень много денег, но при этом редактор настолько убог, что больше похоже на ранний прототип без функциональности. Движок может и не плох, но вот редактор, полное позорище. Учитывая, что разрабы сравнивают с UE4, а там даже и 10% функциональности не наберётся.
Нет уж, спасибо, не надо.
CrazyFizik
И давно бесплатно — это много денег? :-)
AxisPod
75$ в месяц — это бесплатно? Или вы будете выпускать игру с их Splash Screen?
А то что Pro бесплатна до апреля, ну может вы и успеете сделать за пару месяцев проект.
CrazyFizik
Мда. Сплеш — это пичалька, как люди на бесплатном Юнити живут, еще и игры делают и продают — загадка. Вообще профессиональные версии не из-за Splash Screen берут.
Профессиональная версия+ у Xenko идет со всеми исходниками и стоит 150 баксов в месяц. Профессиональная версия Unity3D стоит 125 баксов в месяц и никаких исходников, а за исходники у них там ценник просто конский — за такие деньги я и сам могу такой же говнодвижок разработать. Профессиональная версия Xenko за 75 баксов не имеет ограничений по оборотным средствам, Юнити+ за 35 баксов увы только до 200к баксов, а вообще она аналогична бесплатной версии Xenko.
Ну а у Unreal Engine идет со всеми потрохами, но надо будет отваливать по 5% роялти. Если по деньгам, то этого хватит что бы заплатить за 5 лет вперед за Unity Pro или Xenko Pro+. Впрочем у них есть еще дополнительные корпоративные планы, там уже свои ценники, но Unreal все же из другой весовой категории — более тяжелой.
Так что по цене Xenko сейчас получается самым дешёвым, если не страшно от сплэш-скрина и нет потребности модифицировать движок, то вообще бесплатно (еще раз напомню, шо за возможность модификации Unity3D ценник более чем конский. Ну и да Xenko это честный C# 7-версии, а Unity3D глючный IL2CPP, всмысле совсем глючный — уровня Mono образца эдак 2008-2012 годов, я вообще хз за что Unity деньги берут — за то что каждую версию меняют API и не могут осилить раздельную компиляцию в 2018 году?
AxisPod
Может быть за кол-во поддерживаемых платформ. Да и судя по офф. сайту доступ в Unity3D к исходам появляется в Pro версии. Да и в Unity при этом довольно неплохая инфраструктура с CI, аналитикой и т.д. И вы всё же считаете, что Xenko выгоднее?