Visual Studio での、Xamarin アプリへの Dotfuscator の保護の統合
この手順では、Dotfuscator を使用して Xamarin プロジェクトを保護する方法を段階的に説明していきます。 手順を完了すると、プロジェクトに保護プロセスが統合されるため、このプロジェクトは Visual Studio または MSBuild でビルドするたびに、Dotfuscator によって自動的に保護されるようになります。 アプリがサポートする各プラットフォームにこれらの手順を適用して、アプリを実行するデバイスに関係なく、実績のある階層化された保護戦略を備えたアプリを作成できます。
Dotfuscator をビルド処理に統合する方法
始める前に、Dotfuscator が自身をビルド システムのどこに挿入するのかを理解しておくことは有用です。以下で、さまざまなプラットフォームの Xamarin ソリューションの概要について図解します。
Android
Xamarin Android プロジェクトの場合、Dotfuscator は MSIL のコンパイル後、Xamarin Android apk のパッケージ手順の前に自身を挿入します。
iOS
iOS のビルドはより複雑になります。C# コンパイラと Dotfuscator は Windows で実行され、その後 Xamarin iOS のパッケージ手順は Mac OS コンピューターでリモートに実行されます。
UWP
Xamarin UWP プロジェクトの構造は Xamarin Android プロジェクトと似ています。Dotfuscator は、Appx のパッケージ手順の前に自身を差し込みます。
サンプル アプリ
これらの手順で使用する例は、BugSweeper いう名前の Xamarin.Forms サンプル アプリです。 これは古典的なゲームで、今回は Android、iOS、Windows 10 デバイスを対象としています。
手順の進め方
これらの手順を進める方法が 2 つあります。
弊社がこれらの手順を書き留めながら作成した git リポジトリをダウンロードして、これらの手順がどのように適用されるかを確認することができます。
このリポジトリを参考にして、自身のアプリにこれらの手順を適用することができます。
これらの手順のスクリーンショットをクリックすると、フル サイズで表示できます。
アプリの最初のビルド
まず、protected-bugsweeper リポジトリを複製し、Visual Studio で BugSweeper.sln
ソリューション ファイルを開きます。
BugSweeper.UWP
プロジェクトに関するステップを無視して続けることができます。
ソリューション エクスプローラーに、ソリューション内のプロジェクトが表示されます。
このソリューションは、2 つの .NET Standard ライブラリと、BugSweeper ライブラリを参照するいくつかのプラットフォーム固有の出力プロジェクトで構成されています。
BugSweeper
は、共有ゲーム ロジックとプラットフォームに依存しないビジネス ロジックを含む .NET Standard ライブラリです。 これはBugSweeperTile.dll
を参照します。BugSweeper.Android
は、Android デバイス用の出力プロジェクトです。BugSweeper.iOS
は、iOS デバイス用の出力プロジェクトです。- このプロジェクトの出力アセンブリの名前は
FormsTemplateiOS
です。
- このプロジェクトの出力アセンブリの名前は
BugSweeper.UWP
は、ユニバーサル Windows プラットフォーム(Windows 10)用の出力プロジェクトです。このプロジェクトの出力アセンブリの名前は
BugSweeper.WinUniversal
です。このプロジェクトはビルド
10.0.10240.0
を対象としています。 対象を変更する場合に、5.30.0 より前のバージョンの Dotfuscator Community を使用しているときは、ビルド10.0.15063
(Creators Update)以降を対象としないでください。 そのビルドの参照パスは、以前のバージョンの Dotfuscator ではサポートされていません。 それら以降のリリースの Dotfuscator では、この問題は解決されました。
BugSweeperTile
は、Tile.cs
のコードが格納されている .NET Standard ライブラリです。 このライブラリは、BugSweeper
ライブラリからコードを取り出して新しいライブラリに格納したもので、Dotfuscator によって保護されている間接参照を示します。
アプリをテスト ビルドして実行し、各プラットフォームで意図したとおりに動作することを確認します(就業時間中にゲームをプレイする言い訳ではありません)。 この方法により、既定の Dotfuscator 保護ではアプリが破損または変更されるため、保護を構成する必要があるかどうかを後で認識できるようになります。
これが完了したら、今度はアプリを保護します。
セットアップ
Dotfuscator を Xamarin ビルド パイプラインに統合する前に、保護するプロジェクトとその構成を決定する必要があります。 そのとき、2 つの技術的な前提条件を満たす必要があります。1 つ目は Dotfuscator をインストールし、コマンド ライン インターフェイスを有効にすることで、2 つ目は必要な MSBuild ターゲット ファイルをダウンロードすることです。
保護する対象の選択
Visual Studio のソリューションは複数のプロジェクトで構成され、各プロジェクトで .NET アセンブリが生成されます。 各プロジェクトは、Debug や Release などの複数の構成でビルドすることができます。
以下の手順に記載されている Dotfuscator-Xamarin の保護は、一度に 1 つのプロジェクト/構成の組み合わせに対して機能します。 したがって、最初に、どのプロジェクトと構成を保護するかを決定する必要があります。 選択のためのガイドラインは次のとおりです。
Dotfuscator は、内部ライブラリではなく、配布を目的とするプロジェクトにのみ適用する必要があります。 Dotfuscator は、出力プロジェクト(Android アプリなど)を保護する場合、そのプロジェクトの依存関係のコピー(共有ライブラリなど)も保護します。
すべてのリリース ビルド構成に Dotfuscator を適用する必要があります。 公開するビルドはすべて保護する必要があります。 保護されたビルドをリリースする方法の詳細については、このページの最後にあるセクションを参照してください。
デバッグ用のビルドに Dotfuscator を適用しないでください。 たとえソース コードが入手可能であっても、Dotfuscator による難読化は、デバッグを不可能ではないにしても、はるかに困難にします。
Dotfuscator をインストールしないチーム メンバーが使用するビルドには、Dotfuscator を適用しないでください。 Dotfuscator がプロジェクト/構成に統合されると、Dotfuscator はそのプロジェクト/構成をビルドするための依存関係の 1 つになります。 したがって、そのプロジェクト/構成をビルドするすべてのマシンに Dotfuscator がインストールされている必要があります。
この例の場合は、以下を保護することをお勧めします。
BugSweeper.Android
の Release 構成BugSweeper.iOS
の Release、Ad-Hoc、および AppStore 構成BugSweeper.UWP
の Release 構成
今後引用するために、これらを「保護するプロジェクトと構成」と呼ぶことにします。 保護の作業が完了したら、これらは「保護されたプロジェクトと構成」になります。
これに対し、BugSweeper
ライブラリ(PCL)の共有コードを保護するのはどうでしょうか?
まず、各出力プロジェクトは BugSweeper
ライブラリを参照するので、難読化されていない BugSweeper
ライブラリが出力プロジェクトのバイナリ ディレクトリにコピーされます。
そのあと統合により、難読化されていないこのライブラリ コピーと、難読化されていないプラットフォーム固有のアセンブリの両方が同時に難読化されます。
この方法では、BugSweeper
ライブラリは、指定されたプラットフォームのアプリ内にパッケージライブラリ場合でも保護されます。
同様に、BugSweeperTile
は BugSweeper
ライブラリのプロジェクト参照であるため、BugSweeperTile
も同時に Dotfuscator によって自動的に保護されます。
Dotfuscator のセットアップ
保護されたプロジェクト/構成の組み合わせをビルドするすべてのマシンでは、Dotfuscator をインストールすると共に、そのインストールのコマンド ライン インターフェイスをアクティブにしておく必要があります。
Dotfuscator をセットアップするには
インストールのヘルプについては、インストールのページを参照してください。
インストール後、Dotfuscator Community を登録する必要があります。
こちらにある手順に従って、コマンド ライン インターフェイスのディレクトリの位置を確認します。
コマンド ライン インターフェイスの実行可能ファイル(
dotfuscator.exe
)の絶対パスを書き留めます。これは、後で必要となる Dotfuscator CLI パスとなります。コマンド ライン インターフェイスがアクティブであることを確認します。 コマンド ライン ウィンドウで
dotfuscator.exe -?
を実行します。コマンド ライン ビルドを実行するためには、Dotfuscator を登録する必要があります。 Dotfuscator GUI を実行すると、登録方法が説明されます。
Dotfuscator 用の MSBuild のターゲットとタスクのカスタム セットをダウンロードする
Dotfuscator をインストールした後、次のカスタムの MSBuild のターゲットとタスクもダウンロードする必要があります。
PreEmptive.Dotfuscator.Xamarin.targets
PreEmptive.Dotfuscator.Internal.Tasks.dll
zip ファイルをアプリのソリューション ディレクトリに展開すると共に、ローカル ソース管理に追加することをお勧めします。プロジェクトをビルドするのにローカル ソース管理が必要となります。
この例では、ターゲット ファイルを C:\code\protected-bugsweeper\PreEmptive.Dotfuscator.Xamarin\
ディレクトリに保存し、ローカル ソース管理に追加します。
PreEmptive.Dotfuscator.Xamarin.targets
のパスは、この手順の後半ではターゲット ファイル パスという名前で記載されています。
プロジェクトの選択
最初に、保護したいプロジェクトを決めました。 この手順の残りは、まずそれらのプロジェクトのうちの 1 つに対して実行することをお勧めします。 その後、残りの各プロジェクトについてこの残りの手順を繰り返します。それを行うタイミングは、そのときにお知らせします。
ここからの例では BugSweeper.Android
を取り上げていますが、iOS プロジェクトおよび UWP プロジェクトに必要な詳細についても説明します。
保護されていないアセンブリの表示
続行する前に、リバース エンジニアリングによって、通常の保護されていないアプリで見ることができる内容を知っておくことは役に立つでしょう。 ビルド パイプラインに Dotfuscator を統合した後、これらのステップを繰り返して、アプリがどのように保護されるかを確認します。
逆コンパイルされたバージョンのアプリを表示するには
プロジェクトをまだビルドしていない場合は、Visual Studio でビルドします。
.NET 逆コンパイラ ILSpy をダウンロードします。
ZIP アーカイブを解凍し、
ILSpy.exe
を実行します。ILSpy インターフェイスで、[File]メニューを開いて[Open]を選択します。
出力アセンブリのバイナリ ディレクトリ(例:
C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android\bin\Release
)を参照し、プロジェクトに対応するアセンブリ(例:BugSweeper.dll
とBugSweeper.Android.dll
)を選択します。コード ツリーを使用して、アセンブリの内容を調べます。 元のソース コードとの類似点に注目してください。プライベート メンバーとローカル変数の名前は保持されており、制御フローは本質的に同じです。
ILSpy を閉じます。これは、Visual Studio がファイル システム上のアセンブリにアクセスするときに、ILSpy と競合することがあるためです。
Xamarin プロジェクトへの Dotfuscator の統合
では、Dotfuscator を Xamarin プロジェクトに実際に統合します。
これは、Visual Studio プロジェクト ファイル(例:BugSweeper.Android.csproj
)を編集することで行います。
以降に説明する手順では、ターゲットのインポート、必要なプロパティの設定、プロジェクトへの構成ファイルの追加を行います。 最終的に、次のようなプロジェクト ファイルを作成できます。
ターゲット ファイルのインポート
各 Visual Studio プロジェクト ファイルは、MSBuild 定義を含んでいる 1 つの XML ファイルです。 ダウンロードしたターゲット ファイルをプロジェクト ファイルにインポートすることで、Dotfuscator-Xamarin 統合をプロジェクトに追加することができます。
Dotfuscator-Xamarin MSBuild ターゲット ファイルをインポートするには
Visual Studio でアプリのソリューションを開きます。
ソリューション エクスプローラーで、保護するプロジェクト(例:
BugSweeper.Android
)を右クリックして[プロジェクトのアンロード]を選択します。ソリューション エクスプローラーで、そのプロジェクトを再度右クリックして[編集 <プロジェクト ファイル名>](例:編集 BugSweeper.Android.csproj)を選択します。
プロジェクト ファイルが XML エディターに表示されます。
ファイルのタブを右クリックし、[このアイテムのフォルダーを開く]を選択します。
ファイル エクスプローラーがプロジェクト ディレクトリ(例:
C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android
)を開いて起動されます。プロジェクト ディレクトリからターゲット ファイル パス(例:
../../PreEmptive.Dotfuscator.Xamarin/PreEmptive.Dotfuscator.Xamarin.targets
)までの相対パスを確認します。Visual Studio に戻り、プロジェクト ファイルの終わりまでスクロールします。
</Project>
タグの直前に次の行を挿入します。パスの部分は、手順 7 の相対パスに適切に置き換えます。<Import Project="../../PreEmptive.Dotfuscator.Xamarin/PreEmptive.Dotfuscator.Xamarin.targets"/>
ファイルを保存します。
MSBuild プロパティの設定
この時点で、プロジェクトには Dotfuscator-Xamarin 統合が組み込まれています。ただし、既定では有効になっていません。 MSBuild プロパティを使用すると、保護プロセスを有効にするだけでなく、いくつかの追加パラメーターを設定できます。
Dotfuscator-Xamarin 統合によって認識される MSBuild プロパティがいくつかあります。 これらを設定するには、次のようにします。
Visual Studio において、プロジェクト ファイルをインポートした行のすぐ上の行で、
<PropertyGroup>
をCondition
属性を指定せずに作成します。この新しい
<PropertyGroup>
セクションに次のタグを追加します。Dotfuscator 構成ファイルの名前を設定します。
<DotfuscatorXamarinConfigFileName>DotfuscatorConfig.xml</DotfuscatorXamarinConfigFileName>
Dotfuscator CLI へのパスを設定します。Dotfuscator をセットアップしたときに書き留めた Dotfuscator CLI パスで置き換えます。
<DotfuscatorXamarinCliPath>Dotfuscator CLI パス</DotfuscatorXamarinCliPath>
構成ファイルがまだ存在していないため、新しい構成ファイルの生成を有効にします。
<DotfuscatorXamarinGenerateNewConfigFile>true</DotfuscatorXamarinGenerateNewConfigFile>
「保護する対象の選択」手順で選択した構成で Dotfuscator を実行できるようにします。
<!-- Release に対して Dotfuscator を有効にします --> <DotfuscatorXamarinEnabled Condition="'$(Configuration)' == 'Release'">true</DotfuscatorXamarinEnabled> <!-- Ad-Hoc(iOS のみ必要)に対して Dotfuscator を有効にします --> <DotfuscatorXamarinEnabled Condition="'$(Configuration)' == 'Ad-Hoc'">true</DotfuscatorXamarinEnabled> <!-- AppStore(iOS のみ必要)に対して Dotfuscator を有効にします --> <DotfuscatorXamarinEnabled Condition="'$(Configuration)' == 'AppStore'">true</DotfuscatorXamarinEnabled>
ファイルを保存します。
Dotfuscator 構成ファイルのプロジェクトへの追加
この時点では、Dotfuscator 構成ファイルは存在していません。 このファイルは後で、保護されたビルドを最初に実行した際に Dotfuscator-Xamarin 統合によって生成されます。
しかし、プロジェクト ファイルで作業している間に、構成ファイルのパスをプロジェクトの追跡対象に追加しておくことをお勧めします。 このように、構成ファイルが存在すると、Visual Studio はアプリを再ビルドするかどうかを判断するときに考慮し、変更がない場合は再ビルドをスキップします。これにより、時間が節約されます。
プロジェクトで Dotfuscator 構成ファイルを追跡するには
Visual Studio で、プロジェクト ファイル内の最後の
<ItemGroup>
タグを探します。このタグの終了タグの後に、次の行を追加します。
<ItemGroup> <None Include="DotfuscatorConfig.xml" /> </ItemGroup>
プロジェクトを保存します。
Dotfuscator で保護されたプロジェクトのビルド
これで、保護を有効にしてプロジェクトをビルドできます。 これを行うには、次のようにします。
Visual Studio で、プロジェクト ファイルを閉じます。
ソリューション エクスプローラーで、保護されたプロジェクト(例:
BugSweeper.Android
)を右クリックして[プロジェクトの再読み込み]を選択します。[ソリューション構成]、[ソリューション プラットフォーム]、および[スタートアップ プロジェクト]ドロップダウンを使用して、保護されたビルド構成(例:Release、Any CPU、
BugSweeper.Android
)を実行する構成にソリューションを配置します。ソリューション エクスプローラーで、保護されたプロジェクトを右クリックして[ビルド]を選択します。
ビルドが完了したら、[出力]タブに表示される次のようなテキストを書き留めておきます。
2> Running Dotfuscator with a new config file based on project references... 2> Finished running Dotfuscator with a new config file. 2>C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android\BugSweeper.Android.csproj : warning : Dotfuscator 構成ファイルが存在しなかったため、新しい構成ファイルが生成されました:'DotfuscatorConfig.xml'。
このテキストは、
DotfuscatorConfig.xml
が存在しない場合にのみ表示されることに注意してください。 その後のビルド(すべてのファイルが最新であるためスキップされません)では、異なるテキストが生成されます。2> Running Dotfuscator with config file 'DotfuscatorConfig.xml'... 2> Finished running Dotfuscator.
MSBuild プロジェクト ビルドの出力の詳細がこのテキストの表示に影響することに注意してください。 この手順では、既定値の "最小" を前提にしています。 これを "簡易" に設定すると、初期ビルドの警告だけが表示されます。 これを "標準" またはそれより詳細な設定にすると、これらの行の間に追加のテキスト行が挿入されて表示されます。
詳細レベルを調整した後もこれらのテキスト行が表示されない場合は、再ビルドを行う前に次の点を確認してください。
変更したファイルのプロジェクト(例:
BugSweeper.Android
)をビルドしようとしている。そのプロジェクトの保護された構成(例:Release)をビルドしようとしている。
Dotfuscator のコマンド ライン インターフェイスが有効になっている(関連するセクション、Dotfuscator のセットアップを参照してください)。
プロジェクト ファイルへの変更が保存されている。テキスト エディターでファイル(例:
C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android\BugSweeper.Android.csproj
)を表示し、このセクションで以前に加えた変更を確認します。
エラー メッセージが表示された場合
「Dotfuscator プロセスはエラー コードで終了した」という旨のエラーが表示された場合には、[MSBuild プロジェクト ビルドの出力の詳細]を "標準" に設定すると、より多くの情報を得られます。 リビルドしたときに、次のようなエラーが表示された場合
2> [ビルド出力] 対象アセンブリが見つからないため外部の型を読み込めません
このような場合は、ビルド中の参照エラーの処理セクションを参照してください。
保護されていない構成が正常にリビルドされることを確認します。 そうでない場合は、保護の手順でなく通常のビルドに問題がある可能性があります。
ソリューション エクスプローラーで、保護されたプロジェクトに
DotfuscatorConfig.xml
ファイルが追加されていることを確認します。 これは Dotfuscator 構成ファイルで、プロジェクトの保護方法を決定するものです。- この既定の構成ファイルは、選択したプロジェクト アセンブリ(例:
BugSweeper.Android.dll
)だけでなく、選択したプロジェクトが直接参照および間接参照するプロジェクトから派生したすべてのアセンブリ(例:BugSweeper.dll
ライブラリとBugSweeperTile.dll
ライブラリ)も保護することに留意してください。
- この既定の構成ファイルは、選択したプロジェクト アセンブリ(例:
新しい Dotfuscator 構成ファイルをローカル ソース管理に追加します。
ソリューション エクスプローラーで、保護されたプロジェクトを右クリックして[エクスプローラーでフォルダーを開く]を選択します。
表示されたプロジェクト ディレクトリに、新しいサブディレクトリ
DotfuscatorReports
が存在することを確認してください。 このディレクトリには、難読化処理中に生成されるレポートが格納されます。そのようなレポートには、コード要素の名前の変更方法を示す名前の変更割り当てファイル(Renaming.xml
)も含まれます。この新しいサブディレクトリをまだ無視するようにしていない場合は、ローカル ソース管理の無視リストに追加します。
名前変更の対象除外の構成
この時点で、Dotfuscator はこのプロジェクトの Xamarin ビルド処理に統合されています。 しかし、まだ、アプリに合わせて保護を構成し、実行時に正しく動作することを保証する必要があります。
iOS の場合は、既定の保護を適用した状態で BugSweeper アプリを実行できるはずです。しかし、BugSweeper アプリでバグのフラグを立てた場合でも、表示されるフラグ数が更新されないことに気付くでしょう。 これは、名前変更の対象除外が必要であるということです。
同様に、この時点で Android または UWP で BugSweeper を実行しようとしても、名前の変更の対象除外が必要なため BugSweeper が実行されないことに気づくでしょう。
この例では、次の対象除外が必要です。
- Android:
FlaggedTileCount
プロパティBugCount
プロパティBugSweeperPage
型board
フィールド
- iOS:
FlaggedTileCount
プロパティ
- UWP:
BugSweeper.Board
型board
フィールドInitializeComponent
メソッドOnBoardContentViewSizeChanged
メソッドOnMainContentViewSizeChanged
メソッドOnplayAgainButtonClicked
メソッド
プロジェクトの名前変更の対象除外を見つけ出す方法の詳細については、名前変更の対象除外の例のページを参照してください。
保護されたアセンブリの表示
この時点で、「保護されていないアセンブリの表示」セクションの手順を繰り返して、アセンブリを再検査できます。 今回、アセンブリが提供する情報は、以前に検査したときよりもはるかに少なくなっているはずです。
内部型、プライベート フィールド、ローカル変数は元の名前を持たなくなり、コードに関する意味のある情報が削除されます。
構成ファイルの生成の無効化
Dotfuscator 構成ファイルが存在しない場合は、Dotfuscator-Xamarin 統合により自動的に生成されます。 この機能は、統合を最初に設定するときには役立ちますが、構成ファイルが確立されている場合には微妙な問題を引き起こす可能性があります。
たとえば、Dotfuscator 構成ファイルがソース管理から誤って削除されたとします。 その結果、ビルド サーバーがプロジェクトをビルドするたびに構成ファイルを見つけることができないため、統合によって新しい構成ファイルが生成されて、それが使用されます。 カスタマイズした構成内容はすべて失われるため、正しく動作しないアプリケーションがビルド サーバーによって作成される可能性があります。
この場合、既定の構成ファイルでビルドを続行して警告を発するだけよりも、エラーを出してビルドが失敗する方が望ましいでしょう。 そうすれば、チームは、ビルド処理に何か問題があることを可能な限り早く知ることができ、ソース管理に構成ファイルを再追加することになるでしょう。
Dotfuscator 構成ファイルの生成を無効にし、構成ファイルが存在しない場合にエラーを発生させるには
Visual Studio でアプリのソリューションを開きます。
ソリューション エクスプローラーで、保護されているプロジェクト(例:
BugSweeper.Android
)を右クリックして[プロジェクトのアンロード]を選択します。ソリューション エクスプローラーで、そのプロジェクトを再度右クリックして[編集 <プロジェクト ファイル名>](例:編集 BugSweeper.Android.csproj)を選択します。
プロジェクト ファイルが XML エディターに表示されます。
<DotfuscatorXamarinGenerateNewConfigFile>
タグを探し、その値をtrue
からfalse
に変更します。プロジェクト ファイルを保存して閉じます。
ソリューション エクスプローラーで、保護されたプロジェクト(例:
BugSweeper.Android
)を右クリックして[プロジェクトの再読み込み]を選択します。プロジェクト ファイルの変更をローカル ソース管理にコミットします。
保護の強化
初めて Dotfuscator をプロジェクトに組み込むと、Dotfuscator により既定の保護設定が提供されます。 しかし、Dotfuscator の保護は既定の保護設定よりもさらに強力にすることができます。
ルート チェックの追加
ルート化されたデバイスでアプリが実行されないようにするためのルート チェックを、BugSweeper.Android
に追加することができます。
この例では、ルート チェックは OnSingleTap
メソッド内に配置されており、このメソッドがルート化されたデバイス上で呼び出されると、そのアプリを終了させるように構成されています。
ルート チェックを構成したら、ルート化されたデバイスまたはエミュレーター上で BugSweeper をテストし、バグのフラグを立てるとアプリが終了することを確認できます。
Xamarin アプリにルート チェックを追加する手順の詳細については、Protected-TodoAzureAuth の例を参照してください。
ライブラリ モードの無効化
BugSweeper の名前変更による難読化は、ライブラリ モードを無効化することで強力にすることができます。
Dotfuscator の[入力]タブで、BugSweeper.dll
と BugSweeperTile.dll
のライブラリ モード プロパティのチェックをオフにします。
構成を保存し、Visual Studio でビルドを行ってアプリを実行すると、iOS および UWP プラットフォームではこれらのアセンブリに対してライブラリ モードを無効化した後でも、もう 1 つの名前変更の対象除外が必要になることがわかります。
その場合は、型 BugSweeper.BugSweeperPage
を除外してください。これにより、次回ビルドを行ったときに、アプリが正常に実行されるようになります。
チームへのビルド変更の配布
あなたのマシンでビルドするときにアプリの保護を行ったので、チームで行われるすべての関連ビルドにこの保護ステップを追加する必要があります。
ローカル ソース管理の使用
次の項目がローカル ソース管理に入っていることを調べる必要があります。$
はリポジトリのルート(例:C:\code\protected-bugsweeper\
)とします。
- Dotfuscator-Xamarin MSBuild のカスタム ターゲットおよびタスク(例:
$\PreEmptive.Dotfuscator.Dotfuscator.Xamarin\PreEmptive.Dotfuscator.Xamarin.targets
および$\PreEmptive.Dotfuscator.Dotfuscator.Xamarin\PreEmptive.Dotfuscator.Internal.tasks.dll
)。 - Dotfuscator 構成ファイル(例:
$\BugSweeper\BugSweeper.Android\DotfuscatorConfig.xml
)
ソース管理で以下を無視するようにする必要があります。
- Dotfuscator レポート ファイル(例:
$\BugSweeper\BugSweeper.Android\DotfuscatorReports\
ディレクトリ全体、またはDotfuscatorReports\
という名前のすべてのディレクトリ)
後の手順で、これらの変更をチームの他のメンバーにプッシュします。
ソース管理の変更の共有
ローカル ソース管理の変更を他のチーム メイトと共有することができます(例:git push
)。
チーム メイトのマシンに Dotfuscator がインストールされている場合には、ビルドは自動的に保護されます。
これはビルド マシンにも適用されます。ただし、Visual Studio または MSBuild を使用してプロジェクトをビルドするものとします。
他のプロジェクトへの適用
この時点で、保護対象として選択した残りの出力プロジェクトについて、「プロジェクトの選択」セクション以降のこの手順を繰り返す必要があります。
たとえば、BugSweeper.Android
の保護が完了したとします。
次に、BugSweeper.iOS
、BugSweeper.UWP
の順で当該の手順を繰り返します。
継続的な開発
このセクションでは、出力プロジェクトに Dotfuscator の保護が備わった後、さらにアプリを開発するための一般的なアドバイスを提供します。
名前変更の設定の更新
アプリを開発しているとき、コードを追加したり変更したりすることにより、Dotfuscator の名前変更の対象除外を調整しなければならない場合があります。 必要に応じて、名前変更の対象除外を構成する手順に従ってください。
新しい参照アセンブリの保護
初めて Dotfuscator を Xamarin プロジェクトに統合したとき、Dotfuscator 構成ファイルは自動的に生成されます。 この生成された構成ファイルには、指定された出力プロジェクトで保護されるアセンブリが示されています。
出力プロジェクト自体のアセンブリ(例:
BugSweeper.Android.dll
)出力プロジェクトが直接的および間接的に参照する、ソリューション内の他のプロジェクトから派生したすべてのアセンブリ(例:
BugSweeper.dll
がBugSweeper.Android.dll
の直接参照であるのに対し、BugSweeperTile.dll
はBugSweeper.Android.dll
の間接参照です。BugSweeperTile.dll
では、BugSweeper.Android.dll
を実際に参照するのはBugSweeper.dll
であるためです)。
この入力アセンブリの一覧を手動で更新する必要があるのは、出力プロジェクトに新しいプロジェクト参照を追加した場合だけです(この新しい参照を追加しても構成ファイルは再生成されません)。
新しい入力を追加するには、下記の手順を実行します。
Visual Studio を使って、すべての保護された構成で出力プロジェクトをビルドします。
[ツール]メニューを開き、[PreEmptive Protection - Dotfuscator]を選択します。
ユーザー インターフェイスで、[ファイル]メニューの[開く]から、Dotfuscator 構成ファイル(例:
C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android\DotfuscatorConfig.xml
)を開きます。ナビゲーション ツリーから[設定]を選択し、[プロパティ]タブがまだ選択されていない場合はそれを選択します。
外部プロパティ
configdir
に表示されたパスと、構成プロパティInDir
に表示されたパスを書き留めます。 この 2 つのパスを連結すると、Dotfuscator の入力ディレクトリ(例:C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android\obj\Release\DotfuscatorXamarin\dfin
)になります。ナビゲーション ツリーから[入力]を選択します。
[入力の追加]ボタン をクリックします。
Dotfuscator 入力ディレクトリを参照し、保護対象として追加するアセンブリ(例:
NewBugSweeperProject.dll
)を選択します。アセンブリを絶対パスで追加した後、[入力の編集]ボタンをクリックし、パスのドライブとディレクトリ部分を
${configdir}\${InDir}\
に置き換えます(例:${configdir}\${InDir}\NewBugSweeperProject.dll
)。構成ファイルを保存します。
すべての出力プロジェクトについて手順 3 を繰り返します(例:
C:\code\protected-bugsweeper\BugSweeper\BugSweeper.iOS\DotfuscatorConfig.xml
、次にC:\code\protected-bugsweeper\BugSweeper\BugSweeper.UWP\DotfuscatorConfig.xml
)。
これで、保護されたビルドは、出力プロジェクトにパッケージ化されるときに、新しいアセンブリも保護するようになります。 これは、「保護されたアセンブリの表示」セクションの手順を使用して確認できます。
ビルド中の参照エラーの処理
Visual Studio の最近の更新により、Xamarin 参照アセンブリの格納方法が変更されました。 これにより、これらの参照アセンブリが見つからない古いバージョンの Dotfuscator で問題が発生する可能性があります。 この問題が原因で、Dotfuscator が統合されたプロジェクトを Visual Studio でビルドするときにエラーが発生します。
ビルド エラーが発生した場合は、MSBuild プロジェクト ビルドの出力の詳細を "標準" に設定することで、詳細を見ることができます。 このセクションで説明する問題は、次のようなエラーで示されます。
2> [ビルド出力] 対象アセンブリが見つからないため外部の型を読み込めません: Android.Content.PM.ConfigChanges,Mono.Android, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065 (TaskId:173)
この場合、Dotfuscator は、Xamarin 参照アセンブリ Mono.Android
で型 ConfigChanges
を見つけることができていません。
Visual Studio バージョン 2017 以降ではこの型を自身の参照アセンブリ パス(例:C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\ReferenceAssemblies\
Microsoft\Framework\MonoAndroid\v6.0
)内から見つけることができますが、古いバージョンの Dotfuscator は共通参照アセンブリ パス(例:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v6.0
)のみを調べます。
最初に、最新バージョンの Dotfuscator を使用していることを確認します。 新しいバージョンの Dotfuscator では、この問題に対処しています。 アップデートについては、Dotfuscator Dotfuscator ページを参照してください。
最新バージョンを使用していない場合は、次の回避策があります。
[ツール]メニューを開いて[PreEmptive Protection - Dotfuscator]を選択することで、Dotfuscator のユーザー インターフェイスを開きます。
ユーザー インターフェイスで、[ファイル]メニューの[プロジェクトを開く]から、Dotfuscator 構成ファイル(例:
C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android\DotfuscatorConfig.xml
)を開きます。[設定]ノードをクリックし、[アセンブリ ロード パス]タブを選択します。
[アセンブリ ロード パスの追加]アイコン()をクリックし、Dotfuscator が探すパスを追加します(例:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\ReferenceAssemblies\
Microsoft\Framework\MonoAndroid\v6.0
)。構成ファイルを保存します([ファイル]メニュー)。
[ビルド]アイコンをクリックして、Dotfuscator によってエラーが生成されるかどうかを確認します。
- Visual Studio ではなく Dotfuscator でビルドしているため、ビルドは検証ステップとしてのみ機能します。 保護されたアセンブリをアプリを実行するための出力プロジェクトにパッケージするには、Visual Studio を使ってビルドする必要があります。
必要なすべてのディレクトリに対して手順 4 を繰り返します。
保護されたアプリのリリース
アプリをリリースする準備ができたら、以下の操作を行います。
出力プロジェクトごとに通常どおりアプリをビルドしてパッケージ化します。
各プロジェクトの
DotfuscatorReports\
ディレクトリから、リリースとプロジェクトに関連付けられた安全な場所にレポート ファイルをコピーします。 これらのファイルをエンド ユーザーに配布しないでください。それらのファイルには、何よりも名前変更の難読化を元に戻すために使用できる情報が含まれています。- たとえば、
BugSweeper
のバージョン 2.0 をリリースする場合、C:\code\protected-bugsweeper\BugSweeper\BugSweeper.Android\DotfuscatorReports
の内容を\\company_network_share\release_artifacts\BugSweeper\2.0\Android\DotfuscatorReports
にアーカイブすることができます。
- たとえば、
通常どおりアプリをリリースします。
スタック トレースを使用して問題をトラブルシューティングするときは、アーカイブされた
Renaming.xml
ファイルを使用して、難読化中に名前が変更されたコード要素の元のソース コード名を特定します。