2

私はここに示すコンテンツを採用しており、コンソール アプリケーション タイプのプロジェクトで正常にテスト実行しましたが、ASP.Net Web アプリケーション プロジェクトにコードを適合させようとすると (ビルド エラーをうまく排除するためにいくつかの変更を加えて)、結局は終了します。次の実行時エラーを受け取ります。

「/」アプリケーションでサーバー エラーが発生しました。

スタンドアロンの exe 内で実行していない場合は、exePath を指定する必要があります。説明: 現在の Web 要求の実行中に未処理の例外が発生しました。エラーの詳細とコード内のどこでエラーが発生したかについては、スタック トレースを確認してください。

例外の詳細: System.ArgumentException: スタンドアロン exe 内で実行されていない場合は、exePath を指定する必要があります。

ソース エラー:

24 行目: ShowConfig(); 25 行目: 26 行目: System.Configuration.Configuration config = 27 行目: ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None); 28行目:

私が試みていることは可能ですか、それとも ASP.Net Web アプリケーション プロジェクトに対してまったく異なるアプローチを試みる必要がありますか?

4

1 に答える 1

0

おそらくもっと簡単なアプローチがあると思いますが、保存しようとしているデータの種類とその理由によって異なります。最初に次のことを考慮する必要があります。

  • 衝突。2 人以上の訪問者が、設定ファイルに書き込む Web ページに同時にアクセスできますか?
  • 永続。アプリケーションの再起動後もデータを保持する必要がありますか?
  • スピード。アプリケーションを実行し続けるために、頻繁に設定データが必要ですか?

衝突のリスクがない場合は、ファイルに書き込むことができます (App_Data フォルダーは、このようなファイルの一般的な場所であり、その内容は Web サーバーによって提供されないため、プライベートのままです)。 、書き込み中はファイルをロックする必要があり、これはより複雑です。

永続性が必要ない場合は、ASP.NET アプリケーションの状態を使用できます。これも高速で、ロックの方法を提供しますが、永続的なストレージではないため、アプリケーションを再起動するとデータが失われます。

衝突を防ぎ、永続的なストレージを提供し、アプリケーションがデータに高速にアクセスできるようにする必要がある場合は、これらの両方のアプローチを組み合わせることができます。

于 2012-05-01T17:13:59.410 に答える