はじめに
こんばんは、じぇしかです。最近、習作としてUnityをベースにしたVRプラットフォームを作ってみたいなーと思っている今日この頃なのですが、HTTP/2ベースでオーバーヘッドの少ないgRPCをリアルタイム通信のプロトコルとして使用したいと思っています。
ということで既存の記事を参考にUnityにgRPCの開発環境を導入していたのですが、Grpc.Core ver.2.23.0以降、下記のエラーが発生してしまうようです。
「最近の記事はどう解決しているんだ？」と思ったのですが、使用するGrpc.Coreのバージョンを下げていたり、偶然にも回避できていたりで、この事象に対して明確に触れている情報はほとんど見つかりませんでした。いろいろ試した結果、明確ではないのですが事象の発生条件と解決策が見えてきたので、記述しておきます。
事象の発生条件
まず、事象が発生する状態を示します。環境整備の手順は他の記事を参照してもらえればよいのですが、導入作業を進めると基本的には下記のようなフォルダ構造になるかと思います。
ここでシーンを再生すると、冒頭の事象が発生します。メッセージを読むと、ざっくり「Google.ProtobufがSystem.Memoryを読み込むことができなかった」というような旨のようです。とはいうものの、依存パッケージとして指定されていることもあり、System.Memoryも同じくダウンロードして配置はしています。
ここで私はドはまりして全く進められなかったのですが、いろいろと調べていくうちに、公式フォーラムのとある記事にたどり着きました。
Editor assembly loading issues - "unloading broken assembly", "could not load signature"
Google.Protobufではないものの、同様にSystem.Memoryの参照が上手くできていないようです。同時に、全てのライブラリ (*.dll) を同じフォルダに入れたところ、エラーが解消されているとも書かれています。やや言い争い状態になっているもののUnityのバグではなく、一部のライブラリにおいて依存関係がハードコードされているようで、フォルダが異なると参照ができないようです。
ちなみにこの事象、System.Memoryがver.4.5.2以下であれば何故か発生しません。実はGoogle.Protobufが依存しているSystem.Memoryのバージョンもver.4.5.2以降ではあるのですが、Grpc.Coreがver.2.23.0-pre以降のバージョンでSystem.Memory ver.4.5.3以降に依存するようになったため、このver.4.5.3が必要になっています。その結果として、Google.ProtobufがSystem.Memory ver.4.5.3を参照できなくなり、本事象が発生するようになったようです。
解決策と対応
さて、明確ではないものの原因らしきものが見えてきたところで、エラーを解決させましょう。結論から言うと、"Google.Protobuf.dll"と"System.Memory.dll"を同じフォルダに入れてあげることで、エラーは解消しました。
上記のように、例えば "Assets/Plugins/Assemblies/lib/net4.5" というような名前のフォルダを作って纏めると管理しやすいかと思います。今回は全部同じフォルダに入れていますが、全てのライブラリが依存関係を解決できていないわけではないので、部分的な対応でも大丈夫です。
念の為、テスト用のスクリプトを作成し、今回導入したパッケージを参照できるか確認しておきましょう。エディターのオートコンプリートで表示されるようであれば、適切に参照できていると判断できます。ひとつ注意事項ですが、プロジェクトの読込みができていない状態だとオートコンプリートも出てこないので、Unity上部のメニュー[Assets] > [Open C# Project]でスクリプトを開くようにしてください。
おわりに
以上、Unity上でgRPC環境を構築するときに私がドはまりした事象について、説明しました。成り行きでGrpc.Coreのバージョンを下げたり、Google.Protobufだけ差し替えてみたりと、この事象に触れている記事がほとんど見つからずとても苦労しました。同じような地雷を踏んでしまったときに、助け船として参照してもらえればと思います。
Top comments (0)