Unity で.NET 4.x を使用するUsing .NET 4.x in Unity

Unity のスクリプトの基になっている C# と .NET は、Microsoft が 2002 年に最初にそれをリリースして以来、更新され続けています。C# and .NET, the technologies underlying Unity scripting, have continued to receive updates since Microsoft originally released them in 2002. しかし、Unity の開発者は、C# 言語および .NET Framework に追加され続けている新機能の絶え間ない流れを知らない場合があります。But Unity developers may not be aware of the steady stream of new features added to the C# language and .NET Framework. これは、Unity 2017.1 以前、何年も更新がない .NET 3.5 と同等のスクリプティング ランタイムが Unity で使用されていたためです。That's because before Unity 2017.1, Unity has been using a .NET 3.5 equivalent scripting runtime, missing years of updates.

Unity には、Unity 2017.1 のリリースで、.NET 4.6 にアップグレードされた、C# 6 と互換性のある試験段階のバージョンのスクリプティング ランタイムが実装されました。With the release of Unity 2017.1, Unity introduced an experimental version of its scripting runtime upgraded to a .NET 4.6, C# 6 compatible version. Unity 2018.1 では .NET 4.x と同等のランタイムは試験段階とは見なされなくなり、一方、古い .NET 3.5 と同等のランタイムはレガシ バージョンと見なされるようになりました。In Unity 2018.1, the .NET 4.x equivalent runtime is no longer considered experimental, while the older .NET 3.5 equivalent runtime is now considered to be the legacy version. そして Unity 2018.3 のリリースでは、Unity はアップグレードされたスクリプティング ランタイムを既定の選択とすることとし、さらに C# 7 まで更新することを計画しています。And with the release of Unity 2018.3, Unity is projecting to make the upgraded scripting runtime the default selection, and to update even further to C# 7. このロードマップの詳細および最新の更新については、Unity の ブログ投稿をお読みになるか、同社の「Experimental Scripting Previews forum」 (試験段階のスクリプティングのプレビュー フォーラム) を参照してください。For more information and the latest updates on this roadmap, read Unity's blog post or visit their Experimental Scripting Previews forum. それまでは、以下のセクションで、.NET 4.x スクリプティング ランタイムで現在使用できる新機能を確認し学習してください。In the meantime, check out the sections below to learn more about the new features available now with the .NET 4.x scripting runtime.

必須コンポーネントPrerequisites

Unity で .NET 4.x スクリプティング ランタイムを有効にするEnabling the .NET 4.x scripting runtime in Unity

.NET 4.x スクリプティング ランタイムを有効にするには、次の手順を実行します。To enable the .NET 4.x scripting runtime, take the following steps:

  1. [Edit](編集)、[Project Settings](プロジェクトの設定)、[Player](プレーヤー) の順に選択し、Unity Inspector で [PlayerSettings](プレーヤー設定) を開きます。Open PlayerSettings in the Unity Inspector by selecting Edit > Project Settings > Player.

  2. [Configuration] (構成) 見出しの下で、 [Scripting Runtime Version] (スクリプティング ランタイム バージョン) ドロップダウンをクリックし、 [.NET 4.x Equivalent] (.NET 4.x と同等) を選択します。Under the Configuration heading, click the Scripting Runtime Version dropdown and select .NET 4.x Equivalent. Unity を再起動するように求められます。You will be prompted to restart Unity.

.NET 4.x 同等を選択する

.NET 4.x および .NET Standard 2.0 プロファイルのいずれかを選ぶChoosing between .NET 4.x and .NET Standard 2.0 profiles

.NET 4.x と同等のスクリプティング ランタイムに切り替えたら、[PlayerSettings](プレーヤー設定) ( [Edit](編集)、[Project Settings](プロジェクトの設定)、[Player](プレーヤー) ) のドロップダウン メニューを使用して、 [Api Compatibility Level] (API の互換性レベル) を指定することができます。Once you've switched to the .NET 4.x equivalent scripting runtime, you can specify the Api Compatibility Level using the dropdown menu in the PlayerSettings (Edit > Project Settings > Player). 次の 2 つのオプションがあります。There are two options:

  • .NET Standard 2.0:.NET Standard 2.0. このプロファイルは、.NET Foundation により発行されている .NET Standard 2.0 プロファイルと一致します。This profile matches the .NET Standard 2.0 profile published by the .NET Foundation. Unity では、新しいプロジェクトに .NET Standard 2.0 を推奨しています。Unity recommends .NET Standard 2.0 for new projects. これは .NET 4.x よりも小規模で、サイズに制限のあるプラットフォームで好都合です。It's smaller than .NET 4.x, which is advantageous for size-constrained platforms. また、Unity では、Unity がサポートしているすべてのプラットフォームで、このプロファイルをサポートすることをコミットしています。Additionally, Unity has committed to supporting this profile across all platforms that Unity supports.

  • .NET 4.x:.NET 4.x. このプロファイルでは、最新の .NET 4 API にアクセスできます。This profile provides access to the latest .NET 4 API. これには、.NET Framework クラス ライブラリで利用できるすべてのコードを含み、また .NET Standard 2.0 のプロファイルも同様にサポートしています。It includes all of the code available in the .NET Framework class libraries and supports .NET Standard 2.0 profiles as well. .NET Standard 2.0 のプロファイルに含まれていない一部の API がプロジェクトで必要な場合は、.NET 4.x のプロファイルを使用します。Use the .NET 4.x profile if your project requires part of the API not included in the .NET Standard 2.0 profile. ただし、この API の一部は Unity のすべてのプラットフォームでサポートされていない場合があります。However, some parts of this API may not be supported on all of Unity's platforms.

これらのオプションの詳細については、Unity のブログ投稿を参照してください。You can read more about these options in Unity's blog post.

.NET 4.x API 互換性レベルの使用時にアセンブリ参照を追加するAdding assembly references when using the .NET 4.x Api Compatibility Level

[Api Compatibility Level] (API の互換性レベル) ドロップダウンの .NET Standard 2.0 設定を使用する場合、API プロファイルのすべてのアセンブリが参照され利用可能です。When using the .NET Standard 2.0 setting in the Api Compatibility Level dropdown, all assemblies in the API profile are referenced and usable. ただし、より大きな .NET 4.x プロファイルを使用する場合、Unity に付属するアセンブリの一部は既定で参照できません。However, when using the larger .NET 4.x profile, some of the assemblies that Unity ships with aren't referenced by default. これらの API を使用するには、手動でアセンブリ参照を追加する必要があります。To use these APIs, you must manually add an assembly reference. Unity に付属するアセンブリは、Unity エディターのインストールの MonoBleedingEdge/lib/mono ディレクトリを参照してください。You can view the assemblies Unity ships with in the MonoBleedingEdge/lib/mono directory of your Unity editor installation:

MonoBleedingEdge ディレクトリ

たとえば、.NET 4.x プロファイルを使用していて、HttpClient を使用したい場合、System.Net.Http.dll に対するアセンブリ参照を追加する必要があります。For example, if you're using the .NET 4.x profile and want to use HttpClient, you must add an assembly reference for System.Net.Http.dll. これがない場合、アセンブリ参照がないことがコンパイラーによって通知されます。Without it, the compiler will complain that you're missing an assembly reference:

アセンブリ参照がない

Visual Studio では Unity のプロジェクトが開かれるたびに、.csproj と .sln のファイルが再生成されます。Visual Studio regenerates .csproj and .sln files for Unity projects each time they're opened. そのため、プロジェクトを開くときに失われてしまうので、Visual Studio に直接アセンブリ参照を追加できません。As a result, you cannot add assembly references directly in Visual Studio because they'll be lost upon reopening the project. 代わりに、mcs.rsp という特別なテキスト ファイルを使用する必要があります。Instead, a special text file named mcs.rsp must be used:

  1. ご使用の Unity のプロジェクトのルートの Assets ディレクトリに mcs.rsp という名前の新しいテキスト ファイルを作成します。Create a new text file named mcs.rsp in your Unity project's root Assets directory.

  2. 空のテキスト ファイルの最初の行に、-r:System.Net.Http.dll と入力しファイルを保存します。On the first line in the empty text file, enter: -r:System.Net.Http.dll and then save the file. "System.Net.Http.dll" は、参照が見つからない含まれているすべてのアセンブリに置き換えることができます。You can replace "System.Net.Http.dll" with any included assembly that might be missing a reference.

  3. Unity エディターを再起動します。Restart the Unity editor.

.NET との互換性を利用するTaking advantage of .NET compatibility

Unity のユーザーは、NET 4.x スクリプティング ランタイムで、新しい C# の構文と言語機能に加え、従来の .NET 3.5 スクリプティング ランタイムとは互換性がない .NET パッケージの大規模なライブラリにアクセスできるようになります。In addition to new C# syntax and language features, the .NET 4.x scripting runtime gives Unity users access to a huge library of .NET packages that are incompatible with the legacy .NET 3.5 scripting runtime.

NuGet から Unity プロジェクトにパッケージを追加するAdd packages from NuGet to a Unity project

NuGet は、.NET のパケット マネージャーです。NuGet is the package manager for .NET. NuGet は Visual Studio に統合されています。NuGet is integrated into Visual Studio. ただし、Unity のプロジェクトで NuGet のパッケージを追加するには、特別な手順が必要です。However, Unity projects require a special process to add NuGet packages. これは、Unity でプロジェクトを開いた場合、その Visual Studio のプロジェクト ファイルが再生成され、必要な構成が元に戻されてしまうためです。This is because when you open a project in Unity, its Visual Studio project files are regenerated, undoing necessary configurations. NuGet から Unity のプロジェクトにパッケージを追加するには、次を実行します。To add a package from NuGet to your Unity project do the following:

  1. NuGet を参照し、追加する互換性パッケージを探します (.NET Standard 2.0 または .NET 4.x)。Browse NuGet to locate a compatible package you'd like to add (.NET Standard 2.0 or .NET 4.x). この例では、JSON を使用する場合の一般的なパッケージである Json.NET を .NET Standard 2.0 プロジェクトに追加する例を示します。This example will demonstrate adding Json.NET, a popular package for working with JSON, to a .NET Standard 2.0 project.

  2. [ダウンロード] ボタンをクリックします。Click the Download button:

    [ダウンロード] ボタン

  3. ダウンロードしたファイルを探し、拡張子を .nupkg から .zip に変更します。Locate the downloaded file and change the extension from .nupkg to .zip.

  4. zip ファイル内の lib/netstandard2.0 ディレクトリに移動し、Newtonsoft.Json.dll ファイルをコピーします。Within the zip file, navigate to the lib/netstandard2.0 directory and copy the Newtonsoft.Json.dll file.

  5. Unity プロジェクトのルートの Assets フォルダーに、Plugins という名前の新しいフォルダーを作成します。In your Unity project's root Assets folder, create a new folder named Plugins. Plugins は Unity の特別なフォルダーの名前です。Plugins is a special folder name in Unity. 詳細については、Unity のドキュメントを参照してください。See the Unity documentation for more information.

  6. Newtonsoft.Json.dll ファイルを Unity のプロジェクトの Plugins ディレクトリに貼り付けます。Paste the Newtonsoft.Json.dll file into your Unity project's Plugins directory.

  7. ご使用の Unity のプロジェクトの Assets ディレクトリに link.xml という名前のファイルを作成し、次の XML を追加します。Create a file named link.xml in your Unity project's Assets directory and add the following XML. これにより、IL2CPP プラットフォームへのエクスポート時に、Unity のバイトコードの削除プロセスで必要なデータが削除されなくなります。This will ensure Unity's bytecode stripping process does not remove necessary data when exporting to an IL2CPP platform. この手順はこのライブラリに特有のものですが、リフレクションを同様な方法で使用するその他のライブラリで問題が発生する可能性があります。While this step is specific to this library, you may run into problems with other libraries that use Reflection in similar ways. 詳細については、このトピックについて Unity の文書を参照してください。For more information, please see Unity's docs on this topic.

    <linker>
      <assembly fullname="System.Core">
        <type fullname="System.Linq.Expressions.Interpreter.LightLambda" preserve="all" />
      </assembly>
    </linker>
    

すべてを配置したら、Json.NET パッケージを使用できるようになります。With everything in place, you can now use the Json.NET package.

using Newtonsoft.Json;
using UnityEngine;

public class JSONTest : MonoBehaviour
{
    class Enemy
    {
        public string Name { get; set; }
        public int AttackDamage { get; set; }
        public int MaxHealth { get; set; }
    }
    private void Start()
    {
        string json = @"{
            'Name': 'Ninja',
            'AttackDamage': '40'
            }";

        var enemy = JsonConvert.DeserializeObject<Enemy>(json);

        Debug.Log($"{enemy.Name} deals {enemy.AttackDamage} damage.");
        // Output:
        // Ninja deals 40 damage.
    }
}

これは、依存関係がないライブラリを使用する単純な例です。This is a simple example of using a library which has no dependencies. NuGet パッケージが他の NuGet パッケージに依存する場合、これらの依存関係を手動でダウンロードし、同じ方法でプロジェクトに追加する必要があります。When NuGet packages rely on other NuGet packages, you would need to download these dependencies manually and add them to the project in the same way.

構文と言語の新機能New syntax and language features

Unity の開発者は、更新されたスクリプトのランタイムを使用して、C# 6 と、多数の新しい言語機能と構文を使用できます。Using the updated scripting runtime gives Unity developers access to C# 6 and a host of new language features and syntax.

自動プロパティ初期化子Auto-property initializers

Unity の .NET 3.5 スクリプティング ランタイムの自動プロパティ初期化子では、初期化されていないプロパティをすばやく簡単に定義できますが、初期化はスクリプトの他の場所で起こる必要があります。In Unity's .NET 3.5 scripting runtime, the auto-property syntax makes it easy to quickly define uninitialized properties, but initialization has to happen elsewhere in your script. .NET 4.x ランタイムでは、同じ行で自動プロパティを初期化できるようになりました。Now with the .NET 4.x runtime, it's possible to initialize auto-properties in the same line:

// .NET 3.5
public int Health { get; set; } // Health has to be initialized somewhere else, like Start()

// .NET 4.x
public int Health { get; set; } = 100;

文字列補間String interpolation

以前の .NET 3.5 ランタイムでは、文字列の連結に面倒な構文が必要でした。With the older .NET 3.5 runtime, string concatenation required awkward syntax. .NET 4.x ランタイムでは、$ 文字列補間機能によって、より直接的で読み取り可能な構文の文字列に式を挿入することができるようになりました。Now with the .NET 4.x runtime, the $ string interpolation feature allows expressions to be inserted into strings in a more direct and readable syntax:

// .NET 3.5
Debug.Log(String.Format("Player health: {0}", Health)); // or
Debug.Log("Player health: " + Health);

// .NET 4.x
Debug.Log($"Player health: {Health}");

式形式のメンバーExpression-bodied members

.NET 4.x ランタイムでより新しい C# 構文が利用可能になったことにより、関数の本文をラムダ式で置き換え、より簡潔にすることができます。With the newer C# syntax available in the .NET 4.x runtime, lambda expressions can replace the body of functions to make them more succinct:

// .NET 3.5
private int TakeDamage(int amount)
{
    return Health -= amount;
}

// .NET 4.x
private int TakeDamage(int amount) => Health -= amount;

また、読み取り専用のプロパティに、式形式のメンバーを使用することもできます。You can also use expression-bodied members in read-only properties:

// .NET 4.x
public string PlayerHealthUiText => $"Player health: {Health}";

タスク ベースの非同期パターン (TAP)Task-based Asynchronous Pattern (TAP)

非同期プログラミングでは、アプリケーションが応答しなくならないようにしながら、時間のかかる操作を行うことができます。Asynchronous programming allows time consuming operations to take place without causing your application to become unresponsive. この機能では、時間のかかる操作の結果に依存するコードが続行される前に、その操作が終わるのを待つこともできます。This functionality also allows your code to wait for time consuming operations to finish before continuing with code that depends on the results of these operations. たとえば、ファイルの読み込みやネットワーク操作の完了を待つことができます。For example, you could wait for a file to load or a network operation to complete.

Unity では、非同期プログラミングは通常コルーチンで実行されます。In Unity, asynchronous programming is typically accomplished with coroutines. ただし、C# 5 以降の .NET 開発で推奨されるのは、System.Threading.Taskasyncawait のキーワードを使用するタスクベースの非同期パターン (TAP) の方法となりました。However, since C# 5, the preferred method of asynchronous programming in .NET development has been the Task-based Asynchronous Pattern (TAP) using the async and await keywords with System.Threading.Task. つまり、async 関数では、残りのアプリケーションのアップデートをブロックせずに、タスクの完了を await できます。In summary, in an async function you can await a task's completion without blocking the rest of your application from updating:

// Unity coroutine
using UnityEngine;
public class UnityCoroutineExample : MonoBehaviour
{
    private void Start()
    {
        StartCoroutine(WaitOneSecond());
        DoMoreStuff(); // This executes without waiting for WaitOneSecond
    }
    private IEnumerator WaitOneSecond()
    {
        yield return new WaitForSeconds(1.0f);
        Debug.Log("Finished waiting.");
    }
}
// .NET 4.x async-await
using UnityEngine;
using System.Threading.Tasks;
public class AsyncAwaitExample : MonoBehaviour
{
    private async void Start()
    {
        Debug.Log("Wait.");
        await WaitOneSecondAsync();
        DoMoreStuff(); // Will not execute until WaitOneSecond has completed
    }
    private async Task WaitOneSecondAsync()
    {
        await Task.Delay(TimeSpan.FromSeconds(1));
        Debug.Log("Finished waiting.");
    }
}

Unity 固有のニュアンスでは、TAP は開発者が考慮すべき複雑なテーマです。TAP is a complex subject, with Unity-specific nuances developers should consider. そのため、TAP は Unity のコルーチンにすべての状況で置き換えられるものではありません。ただし、利用できるもう 1 つのツールではあります。As a result, TAP isn't a universal replacement for coroutines in Unity; however, it is another tool to leverage. この機能の範囲はこの記事では説明しませんが、一般的なベスト プラクティスおよびヒントを以下に示します。The scope of this feature is beyond this article, but some general best practices and tips are provided below.

Unity で TAP を使用開始するGetting started reference for TAP with Unity

次に、Unity で TAP の使用を開始する場合のヒントを示します。These tips can help you get started with TAP in Unity:

  • 待機することが期待されている非同期関数には、Task または Task<TResult> の戻り値の型が必要です。Asynchronous functions intended to be awaited should have the return type Task or Task<TResult>.
  • タスクを戻す非同期関数には、その名前に "Async" のサフィックスが設定されている必要があります。Asynchronous functions that return a task should have the suffix "Async" appended to their names. "Async" のサフィックスは、関数が常に待機している必要があることを示します。The "Async" suffix helps indicate that a function should always be awaited.
  • 従来の同期コードから非同期関数を実行する関数には、async void の戻り値の型のみを使用します。Only use the async void return type for functions that fire off async functions from traditional synchronous code. このような関数は、それだけでは待機できず、名前に "Async" のサフィックスがあるべきではありません。Such functions cannot themselves be awaited and shouldn't have the "Async" suffix in their names.
  • Unity は UnitySynchronizationContext を使用し、既定でメインのスレッドで async 関数が実行されるのを保証します。Unity uses the UnitySynchronizationContext to ensure async functions run on the main thread by default. Unity の API には、メインのスレッド外ではアクセスできません。The Unity API isn't accessible outside of the main thread.
  • Task.RunTask.ConfigureAwait(false) などのメソッドを使用し、バックグラウンド スレッドでタスクを実行することが可能です。It's possible to run tasks on background threads with methods like Task.Run and Task.ConfigureAwait(false). この手法は、パフォーマンスの向上のためにメインのスレッドからコストの高い操作をオフロードする場合に便利です。This technique is useful for offloading expensive operations from the main thread to enhance performance. ただし、バックグラウンド スレッドを使用すると、競合状態など、デバッグが困難な問題につながる可能性があります。However, using background threads can lead to problems that are difficult to debug, such as race conditions.
  • Unity の API には、メインのスレッド外ではアクセスできません。The Unity API isn't accessible outside the main thread.
  • スレッドを使用するタスクは、Unity WebGL のビルドではサポートされていません。Tasks that use threads aren't supported on Unity WebGL builds.

コルーチンと TAP 間の違いDifferences between coroutines and TAP

コルーチンと TAP / async-await の間には重要な違いがあります。There are some important differences between coroutines and TAP / async-await:

  • コルーチンは、値を返すことはできませんが、Task<TResult> はできます。Coroutines cannot return values, but Task<TResult> can.
  • yield は、コルーチンでエラー処理を困難にするので、try-catch ステートメントに入れることができません。You cannot put a yield in a try-catch statement, making error handling difficult with coroutines. ただし、TAP で try-catch は動作します。However, try-catch works with TAP.
  • Unity のコルーチンの機能は、MonoBehaviour から派生しないクラスでは利用できません。Unity's coroutine feature isn't available in classes that don't derive from MonoBehaviour. TAP はそのようなクラスの非同期プログラミングに最適です。TAP is great for asynchronous programming in such classes.
  • 現時点では、Unity で完全にコルーチンに代わるものとして TAP を提案していません。At this point, Unity doesn't suggest TAP as a wholesale replacement of coroutines. プロファイリングは、いかなるプロジェクトでも、1 つのアプローチに対する他のアプローチの特定の結果を知ることのできる唯一の方法です。Profiling is the only way to know the specific results of one approach versus the other for any given project.

Note

Unity 2018.2 以降、改行ポイントを使用した非同期メソッドのデバッグは完全にはサポートされていません。ただし、この機能は Unity 2018.3 で期待されています。As of Unity 2018.2, debugging async methods with break points isn't fully supported; however, this functionality is expected in Unity 2018.3.

nameof 演算子nameof operator

nameof 演算子は、変数、型、メンバーの文字列名を取得します。The nameof operator gets the string name of a variable, type, or member. nameof は、エラーの記録、列挙型の文字列名の取得などで便利です。Some cases where nameof comes in handy are logging errors, and getting the string name of an enum:

// Get the string name of an enum:
enum Difficulty {Easy, Medium, Hard};
private void Start()
{
    Debug.Log(nameof(Difficulty.Easy));
    RecordHighScore("John");
    // Output:
    // Easy
    // playerName
}
// Validate parameter:
private void RecordHighScore(string playerName)
{
    Debug.Log(nameof(playerName));
    if (playerName == null) throw new ArgumentNullException(nameof(playerName));
}

呼び出し元情報属性Caller info attributes

呼び出し元情報属性では、メソッドの呼び出し元の情報を得ることができます。Caller info attributes provide information about the caller of a method. 呼び出し元情報属性では、使用する各パラメーターの既定値を提供する必要があります。You must provide a default value for each parameter you want to use with a Caller Info attribute:

private void Start ()
    {
        ShowCallerInfo("Something happened.");
    }
    public void ShowCallerInfo(string message,
            [System.Runtime.CompilerServices.CallerMemberName] string memberName = "",
            [System.Runtime.CompilerServices.CallerFilePath] string sourceFilePath = "",
            [System.Runtime.CompilerServices.CallerLineNumber] int sourceLineNumber = 0)
    {
        Debug.Log($"message: {message}");
        Debug.Log($"member name: {memberName}");
        Debug.Log($"source file path: {sourceFilePath}");
        Debug.Log($"source line number: {sourceLineNumber}");
    }
// Output:
// Something happened
// member name: Start
// source file path: D:\Documents\unity-scripting-upgrade\Unity Project\Assets\CallerInfoTest.cs
// source line number: 10

Using staticUsing static

Using static では、そのクラス名を入力せずに、静的な関数を使用できます。Using static allows you to use static functions without typing its class name. using static では、同じクラスからのいくつかの静的な関数を使用する必要がある場合、領域と時間を節約できます。With using static, you can save space and time if you need to use several static functions from the same class:

// .NET 3.5
using UnityEngine;
public class Example : MonoBehaviour
{
    private void Start ()
    {
        Debug.Log(Mathf.RoundToInt(Mathf.PI));
        // Output:
        // 3
    }
}
// .NET 4.x
using UnityEngine;
using static UnityEngine.Mathf;
public class UsingStaticExample: MonoBehaviour
{
    private void Start ()
    {
        Debug.Log(RoundToInt(PI));
        // Output:
        // 3
    }
}

IL2CPP に関する考慮事項IL2CPP Considerations

iOS などのプラットフォームにゲームをエクスポートする場合、Unity ではその IL2CPP エンジンを使用して IL を C++ コードに "トランスパイル" します。その後、それはターゲット プラットフォームのネイティブ コンパイラーを使用して、コンパイルされます。When exporting your game to platforms like iOS, Unity will use its IL2CPP engine to "transpile" IL to C++ code which is then compiled using the native compiler of the target platform. このシナリオには、リフレクションの部分や dynamic キーワードの用途など、サポートされていないいくつかの .NET 機能があります。In this scenario, there are several .NET features which are not supported, such as parts of Reflection, and usage of the dynamic keyword. この機能の使用は、ご自分のコードで制御できますが、サードパーティー製の DLL および SDK が Unity と IL2CPP を念頭に入れて記述されていない場合、問題が発生することがあります。While you can control using these features in your own code, you may run into problems using 3rd party DLLs and SDKs which were not written with Unity and IL2CPP in mind. このトピックの詳細については、Unity のサイトでスクリプティングの制限に関する文書を参照してください。For more information on this topic, please see the Scripting Restrictions docs on Unity's site.

また、上の Json.NET の例で示したとおり、Unity は IL2CPP のエクスポート処理時に、未使用のコードを除去しようとします。Additionally, as mentioned in the Json.NET example above, Unity will attempt to strip out unused code during the IL2CPP export process. リフレクションを使用するライブラリでこれが問題となることは通常はありませんが、実行時に呼び出されるプロパティまたはメソッドが偶発的に除去される場合があり、これはエクスポート時には判断できません。While this typically isn't an issue, with libraries that use Reflection, it can accidentally strip out properties or methods that will be called at run time that can't be determined at export time. これらの問題を解決するには、削除プロセスを実行しないアセンブリおよび名前空間の一覧が記述された link.xml ファイルをプロジェクトに追加します。To fix these issues, add a link.xml file to your project which contains a list of assemblies and namespaces to not run the stripping process against. 完全な詳細については、Unity でのバイトコードの削除に関する文書を参照してください。For full details, please see Unity's docs on bytecode stripping.

.NET 4.x の Unity のサンプル プロジェクト.NET 4.x Sample Unity Project

このサンプルには、いくつかの .NET 4.x の機能例が含まれています。The sample contains examples of several .NET 4.x features. プロジェクトをダウンロードしたり、GitHub でソース コードを参照することができます。You can download the project or view the source code on GitHub.

その他の技術情報Additional resources