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 コメント

コメントの配信登録

コメント受付を終了しました。

  1. Kenneth Christensen

    4月 10, 2018 9:44 pm

    Does the 4.x runtime mean that we can access TLS1.2 https endpoints ?

    1. Josh Peterson

      4月 10, 2018 9:45 pm

      No, we still don’t support TLS 1.2 in the Unity 2018.1 release. However, Unity 2018.2 does support TLS 1.2 for all platforms with the .NET 4.x runtime.

  2. I would love to use, it. Unfortunately unit tests do not work with .Net 4.6 in command line. see this bug:
    https://issuetracker.unity3d.com/issues/dot-net-4-dot-6-scripting-runtime-unity-executable-hangs-when-running-tests-in-batchmode

    It has been stuck for months in “Fixed in future release”.

    1. Josh Peterson

      4月 10, 2018 6:54 pm

      I’ve just checked on this. The fix was back ported to 2018.1, so it should be corrected in the latest 2018.1 beta release.

  3. George cook

    4月 4, 2018 6:27 pm

    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.

    :)

    1. Josh Peterson

      4月 5, 2018 1:44 pm

      I don’t follow your request, sorry. Could you elaborate a bit more? Maybe this his something better discussed on the forums.

  4. 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).

    1. Josh Peterson

      3月 30, 2018 2:11 pm

      I don’t see that we have an open bug on VSCode debugging. Can you let me know the bug number or open a new bug report?

      1. When we tried to report them, they were marked as duplicates, and we got link to vscode-unity-debug github issue tracker. It’s full of .NET 4.6 issues, so we stopped reporting them through bug reporter.

      2. Case 944169

        1. Josh Peterson

          3月 30, 2018 4:15 pm

          Thanks for the information. I’ll check with our code editors team to see how we should handle this.

  5. Sir.Thorgeir

    3月 29, 2018 10:42 pm

    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?

    1. Josh Peterson

      3月 30, 2018 2:13 pm

      The editor runs with either the old or the new runtime, depending on the user’s option chosen in the player settings. You can use the NET_4_6 define to use code that should only run with the new scripting runtime. See this page for more details: https://docs.unity3d.com/Manual/PlatformDependentCompilation.html

  6. Is .net core on the radar for the future at all?

    1. Josh Peterson

      3月 29, 2018 1:37 pm

      It is not something we’re looking at for the near future, for a few reasons. First, it does not have a full embedding API, as Mono does. Second, it does not support enough platforms currently. We have done some experiments with it though, so I can’t rule it out entirely. But we’re focused on other priorities at the moment, like build size, iteration time improvement, GC, and C#7.

  7. Wendelin Reich

    3月 28, 2018 10:33 pm

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

    1. The upgrade of Mono means the GC engine changes to SGen, which is generational, http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

    2. Jonathan Chambers

      3月 29, 2018 1:37 am

      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.

      1. I wonder what problems you encountered which don’t allow you to switch GC to SGen?

        1. Josh Peterson

          3月 29, 2018 1:35 pm

          Plenty of native code in Unity Engine has unfettered access to managed memory. This is fine for a conservative, non-moving GC. A moving GC could cause problems for that code. We’re actively working on locking down access to managed memory from our native code so that we can support a different GC in the future.

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

  8. Null propagators here I come!

    1. George Cook

      3月 29, 2018 5:47 am

      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 :)

      1. Alkis Tsapanidis

        3月 29, 2018 12:29 pm

        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

  9. Pra Pangurakan

    3月 28, 2018 9:33 pm

    Thank you Unity for .NET Standard 2!

  10. Very good news. How come c# 7 is not supported?

    1. Jonathan Chambers

      3月 28, 2018 10:11 pm

      We have not yet migrated to Roslyn which is a prerequisite for supporting C# 7.

  11. 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.

    1. Patrick McCarthy

      3月 28, 2018 10:21 pm

      This will definitely help to make many more NuGet packages compatible with Unity.

      NuGet For Unity will absolutely support these new profiles.
      https://assetstore.unity.com/packages/tools/utilities/nuget-for-unity-104640

  12. Russ Painter

    3月 28, 2018 8:24 pm

    Love it! Down with the past. Bring on the future!

  13. Isaac Surfraz

    3月 28, 2018 6:21 pm

    awesome work, keep it up!

    1. George Cook

      3月 29, 2018 5:49 am

      +1