Search Unity

Обновление сборки: быстрое определение используемого API

, Январь 6, 2015

С введением Unity 5.0 мы пользуемся возможностью улучшить некоторые API. Конечно, мы хотим, чтобы процесс обновления был как можно менее болезненным, поэтому мы работаем над автоматическим обновлением API (как обсуждали с Лукасом) с поддержкой как скриптов, так и сборок, используемых в проектах. Есть два основных инструмента, AssemblyUpdater и ScriptUpdater, которые отвечают за применение актуального обновления API.

В случае скриптов определение использования измененного API, которое мы можем автоматически обновить, происходит путем проверки на присутствие определенной строки (UnityUpgradable) в сообщениях об ошибках компилятора, поэтому мы не можем никак повлиять на производительность в этом процессе.

В случае сборок первое, что мы делали, –просто сканировали сборки во время импорта, ища при этом измененные ссылки API. Для большинства разработчиков игр это хорошо работает (так как обычно они не делают импорт сборки в течение всего дня). Но оказалось, что это не оптимальное решение для, по крайней мере, группы разработчиков в Asset Store, которые создают сборки с использованием внешних инструментов (VS, Mono и т.д.) и импортируют их в Unity, чтобы проверить или для чего-то еще.

Для таких случаев мы вводим новый .Net-атрибут (UnityAPICompatibilityVersionAttribute), который может быть применен к сборкам, чтобы указать, что они используют только API, которые совместимы с определенной версией Unity. При запуске средства обновления сборки он проверяет сборку, обрабатываемую для этого атрибута и принимает сборку, не нуждающуюся в обновлении, если версия в атрибуте соответствует текущей версии Unity (Application.unityVersion).

С этими изменениями может быть добавлена следующая строка:

[csharp][assembly: UnityEngine.UnityAPICompatibilityVersion("1.2.3f1")] // in C# and Boo[/csharp]
[js]@assembly: UnityEngine.UnityAPICompatibilityVersion("1.2.3f1") // in UnityScript[/js]
Средство обновления не будет беспокоить при проверке сборки, содержащей этот код, когда она импортируется в Unity (если Unity имеет туже версию, т.е. 1.2.3f1)

Обратите внимание, что у нас нет понятия «обратной совместимости». Это означает, что если вы отметили свою сборку как совместимую с Unity API версии X + 1 и импортируете эту сборку в Unity версии X (конечно, при условии, что версия Unity имеет AssemblyUpdater , то есть, X >= 5.0), AssemblyUpdater будет сканировать сборку, ища кандидатов на обновление.

Еще одно преимущество такого подхода заключается в том, что сборки, которые обновляются автоматически, получат этот атрибут от средства обновления, так что, если по какой-либо причине, сборка снова импортируется (например, пользователь выбирает для ассетов «Reimport All»), обновления будут учитывать атрибут.

Пожалуйста, имейте в виду, что, хотя сейчас это реализовано так, мы рассматриваем другие варианты (например, начать контроль версий сборок UnityEngine), и, если мы решим использовать один из этих вариантов, мы можем изменить алгоритм принятия решения о том, следует ли искать устаревшие используемые API (мы могли бы проверить версию UnityEngine.dll, на которую ссылаются, чтобы сверить с нашей версией UnityEngine).

Не стесняйтесь спрашивать/комментировать.

Комментарии закрыты.

  1. Could we also have this attribute added to the next release of 4.6? It would help with creating a single package compatible with both Unity 5 and 4.

    1. This attribute is only an optimization to allow AS authors to tell the updater that his/her package has no obsolete API usage; this way the updater can completely skip such assemblies and so does not add extra time to the AS author workflow.

  2. Emil "AngryAnt" Johansen

    Январь 8, 2015 в 8:45 дп

    I didn’t see this asked in the comment section of that other post, so here goes:

    Any chance for user scripting of the updater? That would come quite in handy for asset store packages vs. rewriting this effort or putting manual upgrade requirements on the user.

    1. @emil. We’ve had some (basic) discussion about this but nothing official. I think the code is modular enough to support (with some small changes) AS devs (from the top of my head, the major missing part, is a way to allow «custom» configurations» to be specified).

  3. Often scripts and online resources will be using older versions of the APIs.

    Could we see version selection options in the online unity documentation similar to the msdn which allows you to select which version of the relevant assembly {.NET, Visual Studio or Office} you want to view the documentation of?

    1. @Seph, not sure if this is what you mean, but there’s a request for introducing versioning in the docs (marked as Planned

  4. I’d like to see documentation pages and unity test cases marked dirty if they aren’t marked as updated for API / ‘black box’ changes. If your build process does that already you sound good to go.

  5. «…start versioning UnityEngine assembly»

    I like that. Why go through all of that which you explained in this post when you can just bundle 3-5 UnityEngine assemblies for developers to use when, say, they REALLY need to update during the development cycle (which in itself is usually considered a bad idea).

    Am I missing something here?

    I can’t imagine WHAT it will take to maintain UnityAPICompatibilityVersionAttribute and all updaters/injectors/compatibility checkers e.t.c. with each major (or even minor?..) Unity update.
    Is this really rational?