現在、開発チームは、作業中のすべてのWebサイトをローカルマシンのIIS)にセットアップしています。代わりに、組み込みのASP.NET開発サーバーの使用に切り替えることを検討しています。
これは良い考えですか? ASP.NET開発サーバーの使用の長所と短所は何ですか?知っておくべき落とし穴はありますか?
ありがとう。
注意:Winでの実行XP/IIS 5/VS2005
編集:
それがCassiniと呼ばれていることに気づかなかった。 Cassini v IIS here 。
ASP.NET Dev WebServiceができることは何もありませんIISはできません(ブレークポイントなどを設定でき、VSデバッガーをASP.NETランタイムに接続するだけです)。
ただし、ASP.NET Dev WebServiceは実際の運用環境を表すものではないため、運用環境に展開するときに予期しない落とし穴に引っかかる可能性があります。
そのため、すべての開発はローカルマシンでIISを使用して行うことを義務付けています。IISでサイトを構成するのに多くの作業は必要ありません。
それは非常に良い考えです。これにはいくつかの理由があります:
私が知っている唯一の主張は、Cassini組み込みサーバーがIISを真似ていないために奇数のポート番号を使用しているため、非常にまれなEdgeのケースがいくつかあるということです。それに遭遇することはありません、そしてCassiniをプライマリ開発環境として使用しても、開発者がIISマシン上。実際、私の優先セットアップは、ほとんどの小さな作業では最初にCassiniで、次にローカルに展開しますIIS for more in -コードを共有ソースリポジトリに戻す前の詳細なテスト。
[編集]
URLの書き換えについて忘れていました。 IISそのために必要です。そして、組み込みの制限の例XP IIS XPで1つのサイトに制限されています(複数のアプリケーションを持つことができますが、それは異なります)。
いくつかの仮想ディレクトリを設定する必要があったため、1つのプロジェクトでIIS)に切り替える(戻す)必要がありました。これは、ASP.NET開発Webサーバーでは不可能です。
私がここで述べたように: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis 開発者は、 Cassiniはローカルユーザーとして実行されます。これは通常、開発者の管理者アカウントです。開発は、アカウントがアクセスできるすべてのファイルまたはリソースにアクセスできます。これは、IIS 6サーバーで表示されるものとはかなり異なります。
かなり大きなもう1つの問題は、Webサービスのデバッグが、別々のCassiniインスタンスを使用するよりも、IISおよびvdirsを使用する方がはるかに簡単です。
ある時点で、Cassiniで認証が機能しない(開発サーバーに組み込まれている)問題があったことを知っています。
また、ISAPIプラグイン(リライターなど)のようなものをテストする必要がある場合、Cassiniでそれがどのように行われるかはわかりません。
絶えず変化するポートも、私にはかなり当惑しています。また、ソリューション内のWebプロジェクトごとに、Casiniサーバーの別のインスタンスを起動し、それぞれが20〜50 MBのメモリを使用します。
私は常にIISを使用しています。セットアップは非常に簡単で、皆さんはすでにそれを行っています...
私は両方の方法を使用しましたが、組み込みのサーバーを使用するよりも、ローカルでIISを使用することを好みます。少なくとも、最終的な展開設定との一貫性が高くなります。
また、IIS 5.1を使用する場合は、必ず JetStat IIS Admin を取得してください。これにより、デフォルトで無効になっている機能が追加されます。 IIS 5など。複数のサイトをセットアップできる場合など。
VS12では、開発サーバーは非常に遅く、2kバイトのファイルをダウンロードするのに数秒かかります。これはvs10では起こりませんでした。あなたがjqueryファイルとCSSの束を持っているとき、これは本当の問題です。また、すべてのページがすべてのcss/jsファイルを再クエリします。非常に遅い回帰テスト。
私はasp.net開発サーバーで次の制限に遭遇しました:
仮想ディレクトリはサポートされていません。アプリで必要な場合は、IISが唯一の選択肢のようです
クラシックASPページは、開発サーバーでは実行できません。だから、あなたが混合ウェブアプリを持っているなら(私が今クライアントに持っているように)、IISが解決策のようです
設定を構成するための管理UIが必要な場合は、IISの方が適切に機能します
もちろんIISでは、ローカル管理者である必要があります。
もう1つの違いは、Cassiniが32ビットプロセスとして実行され、それを制御できないことです。一方、IISアプリのアプリケーションプールを制御して、32ビットを許可しないと仮定します。 IISは64ビットサーバーで実行されています。)これは、WebアプリケーションがSharePoint Foundation/Server 2010などの64ビットプロセスでAPIを呼び出す場合に特に重要になります。 Cassiniをデバッグサーバーとして使用するWebアプリでは、「URLのWebアプリケーションが見つかりませんでした。URLが正しく入力されていることを確認してください」というオブジェクトのインスタンス化時にタイプエラーが表示されます。IISアプリケーションが64ビットとして実行されるアプリプールで実行され、SharePointデータベースへのアクセスを許可するIDを使用すると、適切にデバッグできます。
私が開発サーバーで遭遇した主な問題は、スレッドコンテキストにカスタムセキュリティプリンシパルが保存されているSerializationExceptionsです。詳細 こちら 。