いくつかの異なる方法でこれを尋ねてみましたが、別のショットを試してみましょう (まだ答えを受け取っておらず、これは私を狂わせています!)
ASP.NET MVC への移行を開始したい非常に大規模な従来の ASP 3.0 アプリケーション (〜 350K 行) があります。古い ASP ファイルを MVC とは別のプロジェクトに保存したいと思います。
これらをデバッグする方法についてのアイデアはありますか? ファイルを同じフォルダーにダンプし、それぞれに必要な関連ファイルとフォルダーを参照する 2 つの異なるプロジェクト (WAP と MVC アプリ) を作成する必要がありますか? これはうまくいくはずですが、誰かがより良いアイデアを持っていますか? アプリケーションの小さな部分を個別に移行する機能が必要です。これにはおそらく 1 ～ 2 年かかると思われます。
多くの調査の結果、IIS の観点からこれらのプロジェクトをマージし、Visual Studio の個別のプロジェクトに保持する良い方法は、プロジェクトを同じフォルダーに作成し、それぞれのファイルを保持することであることがわかりました。独自の .csproj ファイルに。
このように、それらを個別に公開することも、ソリューションとして公開することもできます。ソリューション エクスプローラーを見ると、どのファイルが各プロジェクトに属しているかを簡単に判断できます。アイテムが従来の ASP (これも .NET ではありません) から MVC に移動されるため、ASP プロジェクトの古いフォルダーの名前を から に変更nameしdelete-me-name、MVC プロジェクトに対応する領域を作成します。
これはこれまでのところかなりうまくいっています。その他の唯一の変更点は、global.asx.cs ファイルに .asp ファイルを無視するルート無視ルールを追加したことです。
routes.IgnoreRoute("{resource}.asp/{*pathInfo}");
これまでのところ、すべてが非常にうまく機能しているようです。
免責事項: これは私の頭の中で思い浮かんだことです。
最初のレビューの後、以下で説明する 3 つの代替案があると思います。
1) 1 つのアプリケーションにマージすると、以下の利点が得られます。global.asax を変更する必要があるのは比較的簡単です。mvc ルート、IOC などを設定します。HttpApplication、Session、および Security (フォーム ベースを想定) は機能します。
やや「マイナーな」問題が 1 つありますが、それは tempData を共有しています。これは、ページで SessionStateTempDataProvider をインスタンス化できる場合に作成できるはずです (ビュー ステートと同様に、ロードするための初期化、保存するためのアンロード)。ブログですが、数か月前のスティーブ・サンダーソンだったと思います。
単体テスト/コード カバレッジを追跡するのは難しくなり、それを管理する方法を考える必要があるかもしれませんが、これはまったく別の議論です。
2)このオプションを使用すると、アプリケーションを完全に分離して、新しい一連の問題を継承できます。HttpApplication.* は、異なるフォルダー、コンテキストなどを参照するため、アプリケーションで使用すると問題を引き起こす可能性がありますが、それらが異なるアプリケーションであることを喜んでいるということを無視します
次の大きな問題は、セッションを機能させることです。これは非常にトリッキーであることが判明する可能性があります。セッションがインプロセスの場合、各アプリケーションは他のアプリケーション セッションを認識しません。ただし、セッション状態に SQL またはカスタム キャッシュ サーバーを使用している場合は、手順または参照/構成のいずれかを「ハック」し、アプリケーション間でセッション状態を共有できます - 最悪の場合、独自のセッション プロバイダーを作成する必要があります (私は作成したことがないので、これがどれほど難しいか、または実用的です）。
次の問題はフォーム認証です。標準のシングル サインオンを実行して、MachineKey の検証キーと復号化キーが構成内で同じであることを確認できます。一時データはオプション 1 と同じになります。私には、これを変更するにはあまりにも多くのことが実行可能になるように思えます...
3) asp.net サイトを取得して mvc への参照を追加し、デフォルトのグローバル asax ルーティングなどを追加すると仮定すると、アプリケーションは正常にビルドされますが、/controller/action/id タイプのルートを探すときにルーティング エラーがスローされるため、これを確認する必要があるかもしれません。
これが機能すると仮定すると、2 つのアプリの xcopy マージを "潜在的に" 行うことができます (つまり、展開前に mvc アプリケーションから asp.net アプリケーションにすべてのファイルをコピーします)。両方のアプリケーションが既にマージされた 1 つの大きなプロジェクトを作成することでこれを実行できることはわかっていますが、この方法ではビルド プロセスのかなり後の段階でコードが結合されます。（署名されたアセンブリは、面倒だと思います）。そしてもう一度、一時データの問題に取り組む必要があります...
URL の書き換えや、考慮すべきその他の多くの側面については触れていませんが、それぞれのアプローチには考慮すべき明確な欠点があることに注意してください。
要約すると、最大の問題は、mvc 側からの HttpApplication、Session、TempData、asp.net 側からのビュー ステートになると思います。URLの書き換え、認証が楽になるはずです。
そして、フォレスト・ガンプが言ったように、「それはそれについての私の考えです」.