遅くなって申し訳ありません(できれば、遅すぎることはありません)が、を使用せずにプラグインを使用したい場合は、何かカスタムを作成していて、メインのアプリケーション フレームワークAppManager
に依存したくない場合があります(高度な「魔法」を使用してすべてを連携させる)、次のいくつかの簡単なタスクを自分で行うことができます。DotSpatial
AppManager
1) ファイルへの参照を追加する
(DotSpatial Release Folder)\Windows
Extensions\DotSpatial.Data.Rasters.GdalExtension.dll
プロジェクトに追加します (これはメインのGdalExtension
プラグイン出力ファイルです)。
注: この手順が正しく行われるように、ライブラリ( を参照するもの) をビルドすると、同じフォルダー (つまり、など)から追加のファイルがこのプロジェクトの出力ディレクトリGdalExtension.dll
にコピーされることを確認してください。gdal_csharp.dll
2) この同じフォルダーには、gdalサブフォルダーも含まれています。フォルダー自体をそのまま出力パスにコピーします (通常は...\bin\Release\\
または...\bin\Debug\\
、構成によって異なります)。もちろん、最終的なプロジェクトでは、ビルド後のコピー イベントを使用してプロセスを自動化するか、Ted が回答のステップ 9 で述べているように、アプリケーションのビルド出力にフォルダーをコンテンツとして含めるだけでよいでしょう。
注:出力フォルダーによって、ライブラリの出力パスではなく、アプリケーションの出力パスを参照しています。GdalExtension
アプリケーションが ( を介して)ラスターをロードするタスクを実行するライブラリを使用している場合、gdal
フォルダーはこのライブラリの出力フォルダー内にある必要はありません。最終的なアプリケーションの出力フォルダーに配置する必要があります。その理由は、さまざまな dll ファイルが動的にロードされるため、実行中のアプリケーション フォルダー内で見つける必要があるためです。
3) コードベースのできるだけ早いGdalRasterProvider
段階で、ステップ 1 で追加した dll ファイルによって参照される新しい を作成します。つまり、次の行のようなものをプロジェクトに追加します。
var grp = new DotSpatial.Data.Rasters.GdalExtension.GdalRasterProvider();
その後、投稿の最初のコード行は期待どおりに機能するはずです。したがって、技術的には、元の質問に対する答えは、DefaultDataManager
クラスが実際にラスター ファイルをロードするタスクを実行する適切なプロバイダーを見つけられなかったということです。したがって、null 変数が残ります。
興味深いことに、どこにも参照を保持する必要はありません (つまり、変数 grp で何かを行う)。ソース コードを確認すると、コンストラクター自体が自身をDefaultDataProvider.PreferredProviders
ディクショナリに追加するタスクを実行し、最終的にメソッドの呼び出しでバックグラウンドで呼び出されますRaster.Open(string)
。唯一の「把握しにくい」部分は、アプリケーションの出力パスに gdal フォルダーをコピーすることだけです。GDAL 拡張機能は、プロバイダーのインスタンス化時にそこにある多数の参照をロードし、ロードは " gdal」サブフォルダーは、アプリケーションが存在し、そこから実行されるフォルダーに配置されます。
(プラグインにはさらに 2 つのプロバイダー (GdalImageProvider
とOgrDataProvider
) も含まれていることに注意してください。これら 2 つを機能させるには、それらをインスタンス化するだけでなく、通常はアプリケーション コードの早い段階でのPreferredProviders
辞書に手動で追加する必要があります)。DefaultDataProvider