Search Unity

Unity 2018.1 で新しくなるスクリプティングランタイムと今後の予定

, 3月 28, 2018

Unity 2018.1 ベータ版には、モダンな .NET ランタイムがフルサポートで搭載されます。Unity は、常に進化し続ける .NET のエコシステムに対応し、今後も .NET の世界における最新・最良な機能との互換性を維持して行きます。

これまでの経緯

Unity 2017.1 では、安定版スクリプティングランタイムの試験的なプレビューをはじめて公開しました。バージョン 2017.2 および 2017.3 のリリースサイクル中に、数多くの Unity ユーザーの皆様がこの試験版をご使用になり、有益なフィードバックをご提供くださいました(ありがとうございます!)。また、この開発は Microsoft の Mono および Visual Studio 両チームの優秀なデベロッパーとの密接な協力によって進められました。色々な問題が解決されて不具合の修正が完了したことで、このモダンなスクリプティングランタイムは格段に安定したものとなりました。そしてバージョン 2018.1 をもって、多くの方に広くお使いいただく準備が整いました。まだ使用されたことのない方は、是非お試しになってみてください!

使用するメリット

安定版のスクリプティングランタイムを使うと、多くのモダンな C# や .NET の機能が Unity で利用可能になります。具体的には以下の機能がアクセス可能になります。

  • C# 6
  • .NET 4.7.1 クラスライブラリ
  • .NET Standard 2.0 および 1.x 用にビルドされたアセンブリへの対応
  • IL2CPP によるマネージドコードのデバッグによるデバッグ(スタンドアロンプレイヤー用は Unity 2018.1 では試験版です。近い将来のリリースでフルサポートになる予定です)

どの .NET プロファイルを使用すべきか

安定版のスクリプティングランタイムには 2 つの新しい .NET プロファイルが含まれています。.NET プロファイルは、コードが .NET クラスライブラリに使用できる API サーフェスを定義します。お使いのプレイヤービルド用の .NET プロファイルの選択は、Player Settings(プレイヤー設定)の「Api Compatibility Level」のオプションで行えます。Unity は以下の 2 つの .NET プロファイルに対応しています。

  • .NET Standard 2.0
  • .NET 4.x

.NET Standard 2.0 プロファイルは、.NET Foundation によって公開された同じ名前のプロファイルと同一のものです。新しい Unity プロジェクト用には是非このプロファイルを選択してください。.NET 4.x より小さいので、モバイル端末など、サイズに制約の掛かるプラットフォームに適しています。また、このプロファイルは、Unity が対応しているすべてのプラットフォームで機能するようになります。Unity で使用されるライブラリの開発者の方は、このプロファイルをターゲットにすることをお奨めします。

.NET 4.x プロファイルは最新の .NET 4 API へのアクセスを提供します。これには、.NET Framework クラスライブラリ内にあるすべてのコードが含まれます。またすべての .NET Standard 2.0 プロファイルに対応しているため、.NET Standard 2.0 用に構築されたマネージドプラグインアセンブリとの併用が可能です。.NET 4.x プロファイルは大きな API へのアクセスを提供していますが、その API の一部は、すべてのプラットフォームでは機能しません。.NET Standard で使用できない機能が必要なプロジェクトや、旧コードの含まれるプロジェクトでは、このプロファイルの使用は推奨されません。

今後の予定

Unity 2018.1 で完全にサポートされるモダンなスクリプティングランタイムは、今後のすべての Unity のバージョンで維持されます。また現在、すべてのプラットフォームでの TLS 1.2 への対応や、モダンなスクリプティングランタイムを使用したビルドサイズとビルド時間の削減にも取り組んでいます。

バージョン 2018.1 の新規プロジェクトの初期設定は、引き続き旧スクリプティングランタイムのままになります。2018.x のリリースサイクル中には、この初期設定が安定版のスクリプティングランタイムに変更されます。旧スクリプティングランタイムは、既存のプロジェクトに関してはフルサポートが維持されますが、非推奨化されます。

Unity では、旧スクリプティングランタイムを廃止し、安定版の新スクリプティングランタイムのみに選択肢を絞る方向での急速な取り組みを進めています。すべてのユーザーに、近い将来に安定版の新スクリプティングランタイムへの移行準備を開始していただくことをお奨めします。Unity としては、安定版の新スクリプティングランタイムの整備に比重を移していき、旧スクリプティングランタイムの不具合修正の頻度は落としていきます。旧スクリプティングランタイムの非推奨化と廃止のスケジュールに関しては、追ってお知らせします。

Unity では、この大きな .NET エコシステムの最近の進化に胸を高鳴らせています。その継続的な進化を受け、デベロッパーの皆様に C# 7 などの最新の .NET ツールを Unity で使用していただけるように尽力しておりますので、楽しみにしていてください!

ランタイムのアップグレードや今後公開予定のスクリプティング機能に関して、Unity フォーラムのこちらのコーナーでお話しできることを楽しみにしています!

32 replies on “Unity 2018.1 で新しくなるスクリプティングランタイムと今後の予定”

What’s the chance of getting a new fresh for code files, with hooks for Rider/Visual Studio, so we can build there, and not have to build again in Unity? Can you guys at least bare that in mind as you go forward with this solution..

Edit in a good code editor + compile again == crappy experience – seems like a good time to fix that, perhaps.

:)

vscode debugging still doesn’t work with .NET 4.6. 1. Editor freeze after debug detach. 2. Type names are displayed with whole namespace chain (which makes them unreadable). 3. Breakpoints placed before debugging are not caught. 4. We can’t watch class variables values (they work only if written as this.variableName). These bugs are reported since august 2017. Of course, we could use VS community, but it’s way worse than code. VSCode is way faster, has better intellisense and its source is released with MIT license (we can’t use VS community in our work, because of community license).

This is fantastic news! I am a editor tools developer and I was wondering if the editor itself still runs on the 3.5 run-time? Is there any way for me to leverage the new .NET 4.x profiles without having my consumers switch to them?

Could you tell us what this means for garbage collection? Is generational GC part of the new runtime?

The new Mono does have SGen as an option, but Unity is still using Boehm for now. Migrating to SGen requires additional work on Unity.

Yea, I see now. Keep it going! SGen has much lower latencies than Boehm GC which is crucial for games.

Indeed – I’ve been using them in Unity since 5.6, or since when they had experiemntal support… which is why I know, BE CAREFUL with monobehaviour and gameobject. They both override == to allow you to write those ghastly javascript-esque if statements i.e if (!myGameObject) instead of if (myGameobject != null)..

Point being – the null propagation will cause Null Pointer Exceptions at Runtime.

I had to refactor a couple of 100 of those in my codebase before I worked it out.

Other than that, enjoy – it’s glorious for sure :)

Actually, they override it so that people do not need to check whether the object is alive in C++ land as well as null checking the pointer to it. The implicit bool cast is separately implemented:

public static implicit operator bool(Object exists)
{
return !CompareBaseObjects(exists, null);
}

For more info:
https://github.com/Unity-Technologies/UnityCsReference/blob/11bcfd801fccd2a52b09bb6fd636c1ddcc9f1705/Runtime/Export/UnityEngineObject.bindings.cs

Ah, thank you. Finally, we can forget about back-porting libraries to the obsolete .NET 3.5 API and start using the original packages directly from NuGet. Support for .NET Standard opens the doors to modern and lovely .NET stuff.

Looking forward for more updates in this direction.

Comments are closed.