私が働いているところでは、非常に小さなASP.NETアプリケーションが数多くあります。サイトがプリコンパイルされた形式で展開されていて、アプリケーションを変更する必要がありますが、利用できるコードのバージョンソース管理が古く、開発者は利用できません。アプリのDLLは、逆コンパイルとハックバックをしなければなりません。デプロイメント前にASP.NET 2.0サイトをプリコンパイルする必要がありますか？
理想的には、開発者がテストや生産を通じて変更を急いで変更をチェックすることは理想的ではありません。私たちはポリシーを変更してこれを防止しますが、アプリケーションプールが再起動されるたびにサーバー上のサイトを再起動することは、コードをサーバーに直接アップロードしないでください。ライブソースをダウンロードできる場合は、ソースコントロールと実際のライブバージョンのバージョンを確認する方が簡単です。
VSアップロードのcsファイルをサーバーに直接プリコンパイルしてそこにコンパイルする利点は何ですか？
これは、アプリケーションのサイズと使用頻度によって異なります。定期的に使用されている場合は、アプリケーションプールは1日の終わりにリサイクルされるだけです。午前中に最初に起動するのを待つだけの価値があります。 30分ごとに1回だけヒットすると、毎回再コンパイルを強制すると、プリコンパイルする価値があります。
もちろん、初回実行時にコンパイルするのに非常に時間がかかる非常に大きなアプリケーションの場合は、特に定常的に使用されていない場合は、プリコンパイルが必要です。
私はローカルイントラネット上にいくつかのASP.netアプリケーションを持っています。これらはすべてソースコードとしてデプロイされています。それらのうちのいくつかは、あまり頻繁に使用されていません。しかし、最初のコンパイル後、彼らは常に非常に迅速にアップするようです。 30分のキャッシュタイムアウトについての情報源はありますか？私の経験はそうでないことを示すようです。 – recursive
アプリケーションプールは20分後にリサイクルされます。その直後に起動/コンパイルヒットが発生します。 –
アプリはそれほど大きくなく、ほんのわずかなページとアセンブリではありません。私は、プリコンパイルされていないばかりで、配備されたサーバ上のものにアクセスしようとしました。それらのものにアクセスするのにかかる時間は目立つ（私はそれを探していた）が、それほど悪くはなかった。彼らのほとんどはまた、多くのアクセスを見ることはありません。 – NetHawk
主な利点は、Webサーバーのパフォーマンスをコンパイルすることです。
あなたのコードを誰から守りますか？顧客ですか？ –
実際、IshtarはReflectorを使用して.NETアセンブリを逆コンパイルすることはほとんどありません。 Webサーバーは.csファイルやWeb設定のようなASP.NETで保護されるべきファイルを提供しないので、それは本当に大きな利点ですか？ 私はパフォーマンスが最も一般的な懸念事項であることに同意します。ご回答有難うございます。 – NetHawk
すべてのプログラムはデコンパイルすることができます..しかし、それを読むのは "難しい"のです。コンパイルされていないプロジェクトを公開している場合は、誰でもコードを直接読むことができます。 –
純粋に使いやすさの観点から、単にソースファイルをサーバーにアップロードして、事前コンパイルを忘れてしまいます。これは、コードを保護します。
これは、私が管理しているすべてのサイト、つまり大きなサイトでも行うことです。私は、アプリケーションのより重要な部分を打つことを習慣にして、すべてが機能することを確認します（そして、私がそれにいる間にコンパイルする）。
ここに別の考えがあります。サイトが公開されている場合は、w3c link checkerを手放すことができます。これは、ヒットするすべてのページをコンパイルするという効果があります。とにかく壊れたリンクがないようにするのはいいことです。
簡単に言えば、これらのルーチンチェックでは、ユーザーからの最初の訪問コンパイルの問題がほとんどなくなります。とにかく続くことが良いルーチンなので、それは私のためにうまくいきました。
ありがとう、スティーブ。すべてのページは別々にコンパイルされていますか？パフォーマンスヒットがすべて最初のリクエストにあるようです。 – NetHawk
aspxファイルは別々にコンパイルされます。典型的な構成では、コードビハインドはDLLにロールインされているためではありません。 –
私は、プリコンパイルせずにファイルをアップロード： このように、私のコードは非常にバグがあることから、私はメモ帳++直接サーバーまた
からでそれを修正することができ、ビジュアルWeb開発者2008（フリー1）がありませんコンパイルオプション： - P
私はこの点に答えを寄せています。ファイルのアドホック・ポスティングをプリコンパイルすることには多くの利点がありますが、そのうちの1つは、本番環境とテスト環境のコードが同期して多少なりとも変化しないことです。あらかじめコンパイルすると、テストしたコードが、の時間ごとに生産に向かうコードになることが確実になります。
実行している問題は、事前コンパイルと初回コンパイルのいずれでもありません。代わりに、使用しているソースコントロールの種類に由来します。私が推測しなければならないことは、あなたがVisual SourceSafeを実行していると言います。ブランチングとマージを簡単にしたソース管理システムに切り替える場合は、コードをstableとdevelopmentに分けることができます。バグの修正はdevブランチに対して行われます（有効になったらstableブランチにマージされます）。そうすれば、テストされていないか、そうでなければプライムタイムの準備ができていないコードは、本番サーバー上に終わることはなく、常にstableのコピーを用意する必要があります。
ありがとう、ロブ。私はこれを良い対抗点として反抗的に有用なものとして投票しています。 これは良いプロセスのように見えますが、ここのシステム全体は実際にはアドホックです。あなたはここでSSを使うのは間違いありません。もっと良いものを使いたいです。 – NetHawk
心に来る最初の事は次のとおりです。
アドホック制御不能なコードをハッキングします。
エンドユーザーステークホルダーであり、開発者の受託者責任の対象です。 開発者は、効率的に製品を改善する機会を利用する必要があります。
免責事項：これらのコメントは「現状有姿」と記されており、スペルチェックをしても私は気にしません。
敬具、
DrFunkie
悪いスペルチェックが、上出来の開発者。 :)
ソースコードと標準リリースプロセスをバイパスして、開発者が実動コードを直接変更している場合は、プリコンパイルの心配よりもはるかに大きな問題があります。 – ahockley
合意しましたが、できる限り改善を図っています。私が解決できないほど大きな組織上の問題を抱えていることは、自分のレベルで影響を与えることができるものを気にしない理由ではありません。 – NetHawk