5

元従業員が作成した ASP.NET アプリケーションがあり、これまでガムテープで保持してきました。このアプリは、MVC、NHibernate、およびその他のプロセスを使用して作成されましたが、他のアプリでは使用されていないため、これらをサポートする方法についてはほとんどわかりません。さらに複雑なことに、元のアプリは適切に展開するように構築されていなかったため、どのファイルをどこにコピーして更新を手動で取得するかについて、従業員からの一連の指示に従わなければなりませんでした。C:\Inetpub\wwwroot今日、何かをコピーする前に、アプリが存在するフォルダー全体のバックアップを作成して、更新を試みました。ファイルをコピーした後、通常は変更を適用するだけでアプリ プールをリサイクルしました。代わりに、次のエラーが発生しました。

ファイルまたはアセンブリ 'Antlr3.Runtime' またはその依存関係の 1 つを読み込めませんでした。アクセスが拒否されました。

混乱はしましたが、あまり動揺していませんでした。バックアップ フォルダーをアプリのフォルダーにコピーして戻しました。これにより、更新を試みる前の状態にリセットされているはずです (いくつかのファイルをコピーしただけなので)。ただし、エラーは解決しません。何度か再コピー、アプリ プールの再起動、IIS の再起動などを試みましたが、役に立ちませんでした。これまでのところ、私の Google-fu も役に立たないことがわかっています。役立つと思われる場合は、完全なスタック トレースを提供できます (私には役に立たないように見えます)。私が知る限り、サーバー上で他に何も変更されておらず、フォルダーは元の状態に復元されているため、私は本当に機知に富んでいます(繰り返しますが、私が知る限り...ファイル比較を行っていません100 以上のファイルのそれぞれ)。

4

4 に答える 4

3

サイトをローカルで実行しようとしていない場合、これは当てはまらないかもしれませんが、これは誰かを助けるかもしれません...

本番サーバーの web.config をローカル ワークステーションに持ってきました。プロダクション構成が偽装を使用していることを忘れていました。それが私の問題であることが判明しました。そのユーザーには、私のローカル ワークステーションに対する権限がほとんどありません。

偽装ユーザーをローカル マシンの IIS_WPG に追加すると、ASP.NET 一時ファイルのアクセス許可などに奇妙なことをする必要がなくなります。

この真実に私を導いたこの投稿に脱帽です。

私の解決策は、ローカルの web.config から偽装行を削除することでした

于 2014-07-11T18:26:37.500 に答える
0

wwwroot フォルダと "Temporary ASP.NET Files" C:\WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET の IIS ユーザーのアクセス許可を確認していただけますか? アクセス許可が問題ない場合は、asp.net 一時フォルダーをクリアして、アプリケーションを再度実行してください (このフォルダーのアクセス許可を再度確認してください)。

于 2014-02-18T16:11:42.457 に答える
0

これを修正しました。新しい理由:

展開フォルダーの ACL がめちゃくちゃになっていました (たとえばbin、エクスプローラーのセキュリティの詳細ビューで、親からではなく親の親から権限を継承していることを示すフォルダー)。

サイトのルートからアクセス許可をすばやくリセットすると、すべてが再び機能し始めました。

于 2016-04-18T16:48:08.800 に答える