3

ユーザー設定とアプリケーション設定の両方を保持するために、.NET Windows フォーム アプリケーションが設定メカニズム( [プロジェクト] > [プロパティ] > [設定] ) を使用しているプロジェクトに参加しました。LoadAssembly(<main application EXE file>)メインアプリのいくつかの機能を実行するために使用するコマンドラインツールを作成しました. メインアプリのメソッドを呼び出すと、設定に来るときを除いてすべてが正常に機能します-もちろん、それらがロードされていないため-設定ローダーがスキップされました.

しかし、アプリケーションは設定に大きく依存しているため、その設定ローダーを明示的に呼び出す必要があります。しかし、私はそれを見つけることができません:設定が追加された空の.NETプロジェクトのすべてのファイルを分析しましたが、ロードルーチンはどこにも見つかりません。

最悪でも問題を回避して実装できると思います

  • 設定ファイルの場所
  • そのコンテンツの明示的なロード

しかし、車輪の再発明は好きではありません。特に、.NET プラットフォームでの設定のロードの非透過的な処理は好きではありません。アプリケーションの起動時
にロードするために .NET フレームワークで使用される組み込みコードを呼び出す方法はありますか?My.Settings

注:アプリケーションは VB.NET で作成されていますが、C# でも同じだと思いますので、必要に応じて C# の考え方を提示してください。

4

2 に答える 2

0

最近、設定が処理されるデフォルトの方法では、私のシナリオが許可されておらず、サポートされていないこともわかりました。の評価

ConfigurationManager.OpenExeConfiguration( ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath

元のアプリケーションから呼び出されたときと、読み込まれたアセンブリから呼び出されたときに、異なるローカル設定ディレクトリを提供します。同じメソッドの出力を比較します。

直接呼び出された場合:

C:\Users\Miroxlav\AppData\Local\WindowsApplication1\WindowsApplicationSetting_Url_za1afclumj0mqqjsghdpysdumjr5jd21\1.0.0.0\user.config

別のアプリから呼び出された、読み込まれたアセンブリの一部として呼び出された場合:

C:\Users\Miroxlav\AppData\Local\WindowsApplication1\TestWindowsApplicationSet_Url_cxikfslvgbja50yw4lvnvugko41ou5jz\1.0.0.0\user.config

したがって、デフォルト設定プロバイダーでは、構成ファイルの場所でさえ直接決定できません。 これにより、ロードされたアセンブリの My.Settings を直接取得する可能性のある後続のすべてのステップが基本的に無効になります(ヘルパー ファイルなし、固定設定を使用する追加の回避策など - 既定の設定プロバイダーを維持したまま)

解決策は、ユニバーサルにアクセス可能な場所に設定を保存するカスタム設定プロバイダーを作成することですが、予想よりもはるかにオーバーヘッドが大きくなります。

更新:簡単な回避策として、メイン アプリケーションの開始時に構成の場所を保存するヘルパー ファイルを実装しました。メイン アプリケーションのコードが読み込まれたアセンブリとして起動されると、ヘルパー ファイルに保存された場所にある構成ファイルからMy.Settingsを復元しています。

于 2014-05-03T12:59:44.087 に答える