拡張機能を Visual Studio Code でデバッグする

  • 18 分

エラーを見つけて修正するプロセスは、デバッグと呼ばれます。 Visual Studio Code と AL 言語拡張機能を使用すると、統合されたデバッガーによってコードを検査し、アプリケーションが正常に実行されるかどうかを検証できます。 デバッグ セッションを開始するには、F5 キーを押します。

次の制限に注意してください。

  • 外部コードをデバッグできるのは、コードにコードを表示フラグが設定されている場合のみです。 コードを表示フラグは、app.json コンフィギュレーション ファイルで設定できます。

  • F5 キーを押すたびに、デバッガーが新しいクライアント インスタンスを起動します。 デバッグ セッションを閉じて、新しいセッションを開始すると、新しいセッションは新しいクライアント インスタンスに依存します。 デバッグ セッションを終了するときに、Web クライアントのインスタンスを閉じることをお勧めします。

  • デバッグ セッションの一時停止はサポートされていません。

ブレークポイント

デバッグの基本的な概念は、ステートメントに設定したマークであるブレークポイントです。 プログラム フローがブレークポイントに到達すると、続行するように指示するまで、デバッガーは実行を停止します。 ブレークポイントを指定しない場合、デバッガーが有効であれば中断することなくコードが実行されます。 Visual Studio Code のデバッグ メニューを使用するか、デバッグしたい行で F9 押すことで、ブレークポイントを設定できます。

定義へ移動機能を使用して基本アプリケーション コードにステップ インし、参照されているコード、通常は (.dal) ファイルにブレークポイントを設定できます。 外部コードまたは基本アプリケーション コードにブレークポイントを設定するには、次の手順を実行します。

  1. ベース オブジェクトの変数を作成するか、ページ上でソース テーブルを選択します。

  2. 変数を右クリックして定義へ移動を選択するか、F12 キーを押します。 外部ファイル (.dal ファイル) が開きます。

  3. ブレークポイントを挿入したい行を選択し、F9 キーを押します。

デバッグのショートカット

デバッグ中に、いくつかのショートカットを使用してデバッグを開始または停止する、またはコードにステップ オーバーまたはステップ インすることができます。

  • F5 - デバッグの開始

  • Ctrl+F5 - デバッグなしで開始

  • Shift+F5 - デバッグの停止

  • Ctrl+Shift+F5 - 公開せずにデバッグを開始します。 デバッガーは、Visual Studio Code 環境で有効になっているバージョンではなく、最後に発行されたバージョンをデバッグします。

  • Alt+F5 - デバッグを使用した Rapid Application Development の開始

  • F10 - ステップ オーバー

  • F11 - ステップ イン

  • Shift+F11 - ステップ アウト

  • F12 - 定義へ移動

エラーで中断

launch.json 構成ファイルでは、breakOnError プロパティを使用することにより、次のエラーの発生時にデバッガーが中断するかどうかを指定できます。 デバッガーが breakOnError に設定されている場合は、コードで処理されるエラーおよび処理されないエラーで実行が停止されます。

breakOnError プロパティの既定値は trueであり、既定でエラーをスローする実装をデバッガーが停止することを意味します。 エラー処理プロセスをスキップするには、launch.json で breakOnError プロパティを false に設定します。

launch.json ファイルの breakOnError 設定では、以下の値のいずれかが使用されます。

  • true - すべてのエラーで中断します。

  • false - いずれのエラーでも中断しません。

  • None - いずれのエラーでも中断しません。

  • All - すべてのエラーで中断します。

  • ExcludeTry - Try 関数のコンテキストの外部で発生した場合のみ、エラーで中断します。

true と false の値は、下位互換性のために現在保持されています。 これらは All と None にマップされます。 今後は後者を使用することをお勧めします。 True と false は将来のバージョンでは廃止される可能性があります。

レコードの変更時に中断

launch.json 構成ファイルでは、breakOnRecordWrite プロパティを使用することにより、レコードの変更時にデバッガーが中断するかどうかを指定できます。 デバッガーがレコードの変更時に中断するように設定されている場合は、レコードを作成、変更、または削除する前に中断します。

breakOnRecordWrite プロパティの既定値は false であり、デバッガーが既定でレコードの変更を中断するように設定されていないことを意味します。 レコードの変更時に中断するには、launch.json ファイルで breakOnRecordWrite プロパティを true に設定します。

launch.json ファイルの breakOnRecordWrite 設定では、以下の値のいずれかが使用されます。

  • true - すべてのレコード書き込みで中断します。

  • false - いずれのレコード書き込みでも中断しません。

  • None - いずれのレコード書き込みでも中断しません。

  • All - すべてのレコード書き込みで中断します。

  • ExcludeTemporary - 一時テーブルに変更が生じない場合にのみ、レコードの書き込みで中断します。

true と false の値は、下位互換性のために現在保持されています。 これらは All と None にマップされます。 今後は後者を使用することをお勧めします。 True と false は将来のバージョンでは廃止される可能性があります。

リソース公開ポリシーの設定

拡張機能を開発する場合、既定では、コードはダウンロードやデバッグから保護されます。 拡張機能へのダウンロードやデバッグに対する知的財産 (IP) 保護の追加については、こちらを参照して、拡張機能のソース コードを確認してください。

拡張機能開発パッケージには、拡張機能のコードの表示またはダウンロードから保護するための構成済みの設定が用意されています。 ただし、この設定はマニフェスト、つまり app.json ファイルでも制御できます。

新しいプロジェクトを開始すると、作成中の拡張機能に関する情報を含む app.json ファイルが自動的に生成されます。 app.json ファイルでは、さまざまな操作中にリソースとソース コードのアクセシビリティを定義する resourceExposurePolicy という設定を指定できます。

resourceExposurePolicy の設定では、次のオプションの一覧を指定します。

  • allowDebugging

  • allowDownloadingSource

  • includeSourceInSymbolFile

これらの各プロパティは、拡張機能のソース コードにアクセスできる特定の領域を定義します。 既定ではすべてのオプションが false に設定されています。つまり、既定では、依存拡張機能は拡張機能のソース コードをデバッグまたはダウンロードできない、ということです。

次に、AL: Go! を使用して生成された場合の既定値を含む JSON ファイルの例を示します。 コマンド:

... "resourceExposurePolicy": { "allowDebugging": true, "allowDownloadingSource": false, "includeSourceInSymbolFile": false }, "runtime": "8.0", "keyVaultUrls": [ "https://mykeyvault.vault.azure.net" ], "applicationInsightsConnectionString": "MyConnectionString1234" ...

resourceExposurePolicy 設定は、生成時に app.json ファイルには表示されません。 既定値を false から変更する場合は、上記の構文の例に示すように設定を追加する必要があります。

allowDebugging

拡張機能でのデバッグを許可するには、拡張機能が依存関係として取得されるときに allowDebugging フラグを設定する必要があります。それ以外の場合、デバッグは許可されません。 拡張機能のデバッガーでソース コードを表示できるようにするには、app.json ファイルの allowDebugging プロパティを true に設定する必要があります。

たとえば、開発者が拡張機能 A を開発し、開発者本人または同じチームの別の人が拡張機能 B を開発して、B が A に依存している場合、A のメソッドが呼び出され、拡張機能 A の app.json ファイルで allowDebugging フラグが true に設定されている場合にのみ、B をデバッグすると A のコードにステップインします。

メソッドと変数で [NonDebuggable] 属性を指定していない限り、allowDebugging プロパティを true に設定すると、このコードにステップインできます。 ただし、メソッドおよび変数を [NonDebuggable] 属性でマークした場合は、デバッグできません。

allowDebugging フラグの既定値は false です。 拡張機能を拡張しているユーザーが信頼できる場合にのみ、このフラグを true に設定することをお勧めします。 allowDebugging を true に設定すると、コードを拡張するすべてのユーザーがデバッグにアクセスできます。 コードへのアクセスを許可するユーザーを一部に限定する場合は、リソース ポリシーを上書きできます。

allowDebugging フラグが false に設定されているにもかかわらず、コードをデバッグできる場合があります。 次のようなことを行うことができます。

  • 拡張機能が Visual Studio Code を使用して DEV 拡張機能としてデプロイされた場合、コマンドレットを使用してデプロイされた場合とは異なり、Business Central の拡張機能管理ページまたは AppSource を使用すると、他のユーザーがコードを表示できます。

  • AL のカスタム外部ツールは、Visual Studio Code によってトリガーされるデバッガーのイベントをリッスンすることで、デバッガーによって公開される DAL 情報にアクセスできる場合があります。

allowDownloadingSource

拡張機能 A の app.json ファイルでこの設定を true に設定すると、拡張機能 A のソース コードとメディア ファイルをダウンロードできます。 たとえば、Business Central の拡張機能管理ページの [ソースのダウンロード] オプションから実行できます。 拡張機能 A は、PTE 拡張機能または DEV 拡張機能です。 allowDownloadingSource の既定値は false です。

includeSourceInSymbolFile

拡張機能 A の app.json ファイルで true に設定されている場合、記号のダウンロード機能を使用してアクセスされる Visual Studio Code でダウンロードされた記号ファイルには拡張機能 A の記号、ソース コード、およびその他のすべてのリソースが含まれます。コードを表示する定義へ移動も、このプロパティに依存しています。 includesourceInSymbolFile の既定値は false です。

AL コンパイラの診断メッセージ

コード アナライザーをコンパイルまたは実行すると、診断メッセージがエラー、警告、情報メッセージの形式で表示されます。 このような診断上の問題を解決するために、問題の原因に関する追加のドキュメントの URL と、問題の解決方法に関するオプションがメッセージに含まれるようになりました。

コンパイルやコード アナライザーからの診断メッセージにリンクを設定すると、問題の原因に関する追加の関連ドキュメントおよび問題の解決方法に関するオプションへのリンクがサポートされます。

すべての診断の問題とコンパイラ出力診断からの URL リンクについては、ドキュメント ページがあります。 それでも、最初のうちは、ドキュメントの内容が充実しておらず、メッセージが主体になります。 パートナーに対しては、文書化を優先的に行うトピックに関するフィードバックを依頼したり、問題の解決に役立つコンテンツに関するフィードバックの共有を依頼しています。 これをもとに、ドキュメントが時間の経過とともに充実し、原因と修正に関するヒントやテクニックを通じてパートナー間で知識が共有され、各診断にかかる時間が短縮されることが期待されます。

最新の AL Compiler 診断についての記事では、例や参考資料を確認できます。

Visual Studio Code から特定の会社で起動する

Business Central テナントでは複数の会社を使用できます。 アプリのデバッグまたはテストを行う場合、多くの場合、特定の会社のコンテキストでこれを行いたいと考えるでしょう。 Business Central の以前のバージョンでは、Visual Studio Code でクライアントを起動した場合、どの会社を使用するかを制御できませんでした。 通常、最初にクライアントで既定の会社を設定する必要があります。

新しい startupCompany パラメーターが Visual Studio Code launch.json 構成ファイルに追加されました。 実行やデバッグを行う場合など、クライアントが Visual Studio Code から起動される際に使用する会社を指定するために使用します。

AL デバッグ中に SQL Server 情報を表示する

直接SQLにアクセスすることなく、クラウド サンドボックスで開発やトラブルシューティングを行う場合のデータベース ロックを理解するのは難しいかもしれません。 たとえば、rec.Modify() メソッドや rec.FindSet() メソッドなど、呼び出し時に AL から取り出されるロックがどれかを特定するのは困難です。 SQL ロックは現在 Web クライアントで確認できますが、別のセッションで別のブラウザーを必要とするため、これをデバッグに対して使用するのは厄介です。

これを支援するために、Visual Studio Code AL デバッグ エクスペリエンスの変数ウィンドウでデータベース統計を拡張すると、デバッグされたセッションの SQL ロックが表示されます。

最後に実行された SQL ステートメントおよびデータベース統計に加えて、デバッグ中のセッション中に発生しているアクティブな SQL ロックに関する情報を取得できます。 この一覧は、AL コードのステップ実行時に更新されます。 コミットを実行すると、保持されているロックが削除されます。

システム アプリケーションのデバッグ

SecureText データ型が最近導入され、システム アプリケーションのデバッグが可能になります。これはアプリケーションの開発やトラブルシューティングを行う際にも、またシステム アプリケーションへのオープン ソース貢献においてもメリットの大きいものです。

デバッグ時にシステム アプリケーションのコード ベースにステップ インしてフローを理解し、変数を調べることも、新しい SecureText データ型でコードが保護されていなければ可能です。

システム アプリケーションをデバッグできれば、AppSource や 顧客固有アプリケーションの開発とトラブルシューティングに便利であると同時に、https://github.com/microsoft/BCApps を使用してシステム アプリケーションにコードを提供するためにも役立ちます。