問題タブ [appsettings]

ログ ファイルを生成する C# コンソール アプリケーションを作成しようとしています。ログ ファイルの保存場所にある程度の柔軟性を持たせたいと考えています。

私は Settings.settings ファイルを次のように使用してみました:

名前: logDrive タイプ: 文字列 スコープ: アプリケーション 値: C:\Scripts\Logs

私のコードでは、次のものを使用しています。

上記をコンパイルすると、「指定されたパスの形式はサポートされていません」というエラー メッセージが表示されます。

それが役立つ場合、次の値:

logDrive = "C:\Scripts\ServiceDesk\Logs" logFile = "3-23-2009 1:20 PM.log"

より良いアプローチおよび/または私が間違っていることについて、誰かが考え/推奨事項を持っていますか?

WPFでは、設定で定義された値でバインディングを使用できますか? 可能であれば、サンプルを提供してください。

Web.Config xml の AppSettings ノードが別のファイルに格納されている ASP.Net アプリがあります。

したがって、私の Web.Config には次のものが含まれています。

そこで設定を変更するたびに、iisreset を実行して強制的に変更を有効にする必要があります。つまり、このファイルの変更は、Web.Config の変更と同じようには検出されません。

Web.Config の場合のように、これらの変更を自動的に有効にする方法を知っている人はいますか?

ありがとう！

.ascxユーザーコントロールで、web.configに保存した値を使用してリンクを動的に生成しようとしています。

実行しようとすると、パーサーエラーが発生します

私はおそらく比較的マイナーなものが欠けていることを知っています。

ASP.NET マークアップから直接 AppSettings にアクセスするための構文は何ですか? 正確には覚えていませんが、「<%= $.settingname %>」のようなものでした。

私は実際には.NET関連のものの学習段階にあり、アプリケーションを保存する方法を模索していました. 設定を XML ファイルに保存する独自のクラスを作成したところ、.NET 自体がアプリケーション設定の保存をサポートしていることがわかりました。

しかし、私はそれを行う2つの方法を見つけました。Visual Studio 2008 で新しい項目の追加ダイアログを開くと、設定ファイル (.settings) または構成ファイル (.config) を作成するオプションが表示されます。両方の違いと、どのシナリオで使用する必要がありますか?

WinForm の位置とサイズの復元に関する多くの投稿があります。

例:

• www.stackoverflow.com/questions/92540/save-and-restore-form-position-and-size
• www.codeproject.com/KB/dialog/restoreposition.aspx?fid=1249382&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2595746

しかし、複数のモニターでこれを行うコードをまだ見つけていません。

つまり、モニター 2 のウィンドウで .NET Winform アプリを閉じた場合、ウィンドウのサイズ、場所、状態をアプリケーション設定に保存して、後でアプリを再起動したときにモニター 2 に復元できるようにします。上記のコードプロジェクトの例のように、保存された場所がほとんど画面外にある場合に「修正」するなど、いくつかの健全性チェックが含まれていると便利です。または、保存された場所がもう存在しないモニター上にある場合 (たとえば、ラップトップが 2 番目のモニターなしで単独で使用されるようになった場合)、モニター 1 に正しく移動します。

何かご意見は？

私の環境: C#、.NET 3.5 以下、VS2008

「.NET アプリに設定を保存するにはどうすればよいですか?」というような質問に対する回答をよく目にします。次のように、手動で app.config (または web.config) にエントリを追加して、app.config ファイルを編集します。

次に、次のようにアクセスします。

上で概説したアプローチを「app.config」アプローチと呼びます。プロジェクトに「設定」ファイルを追加することを勧める人はめったにいません。私はこれをウェブやスタックオーバーフローで何度も見てきました...何かが足りないのではないかと思い始めています...なぜなら、「設定" ファイル。私は VS2005 まで .NET を使用していなかったので、私が持っている 1 つの理論は、これは VS2003 で行われた方法であり、人々は決して切り替えなかったということですか?

app.config アプローチを推奨する人々の例:

• Windows フォーム C# アプリケーションで構成ファイルを使用する最も簡単な方法
• ベストプラクティス: C# (フォーマット/タイプ) で設定を保存するにはどうすればよいですか?

私の見解では、「設定ファイル」アプローチには次の利点があります。

1. アプリケーション設定 (すべてのユーザーに共通の設定) とユーザー設定の両方を同じインターフェイスから使用できます。
2. Visual Studio で設定デザイナー サポートを使用する機能。XMLファイルを直接編集するよりもエラーが発生しにくいです。
3. リファクタリング - 特定の設定名の名前を変更すると、コード内の参照が自動的に更新されます。
4. コンパイルの型チェック。
5. オートコンプリートのサポート。
6. プロパティ グリッド機能。PropertyGrid コントロールは、クイック オプション フォームを作成するための非常に簡単な方法であることがわかりました。やるだけでpropertyGrid1.SelectedObject = Settings1.Default;完了です。

「設定」ファイル アプローチの意味がわからない場合は、この投稿を参照してください。これは、app.confg の代わりに設定ファイルを使用することを推奨する数少ない例の 1 つです。

編集: 理解してください: このトピックの意図は、人々が設定ファイルのアプローチよりも上で概説した app.config アプローチを使用する理由を理解することです。私は、設定ファイルのアプローチの限界に直面し、時には独自のカスタム ソリューションをロールバックすることを余儀なくされました。それはまったく別の議論です。

タイプセーフなアプリケーション設定を使用すると、app.exe.config ファイルに次のようなものがあります。

Settings.Designer.vb は次のようなことを行います。

そして、次のような方法で設定にアクセスできます。

Settings.IntervalTimeout

この設定の変更を外部から監視するためのベスト プラクティスは何ですか。つまり、設定はサービスとして実行されているアプリケーションによって使用され、誰かが対応する構成ファイルを開いて IntervalTimeout を 30 などに変更すると、サービス アプリケーションは通知を受け取り、自分自身を再構成するために私が指示したことを何でも実行します。

通常、初期化中に次のようなものを使用していました。

そして、変更されたプロパティの名前をチェックし、適切に反応する Eventhandler を実装します。

ただし、PropertyChanged イベントは、Set メソッドがプロパティで呼び出されたときにのみ発生し、誰かがファイル内のデータを直接変更した場合には発生しません。もちろん、これは天国だったでしょうが、これがうまくいかないことは理解できます。;-)

おそらく、filesystemwatcher を実装してファイルの変更を監視し、構成をリロードして、何が変更されたかを調べ、それらの変更を反映するために必要なことをすべて実行します。

誰かがより良い方法を知っていますか? それともサポートされているものですか？