過去に、プロジェクトの早い段階で SqlServer / StateServer を使用するようにというアドバイスを聞いたことがあります。そのため、スケーリングするときに、シリアル化できないオブジェクト InProc を使用する開発者の罠にはまらず、後で SqlServer / StateServer に移行するときに壊れてしまいます。
起動したばかりなので、現時点では SqlServer セッション状態の InProc を使用する必要はありませんが、おそらくかなり迅速にスケーリングする必要があります。
InProc を使用するときにシリアライズ可能なオブジェクトを強制することについて、誰かに推奨事項はありますか? おそらくラッパーを作成していますか？
SqlServer / StateServerの使用は、スケールアウト（Webファーム）だけではないことを覚えておくことが重要です。1台のサーバーでも、InProcセッションを使用するだけで問題が発生する可能性があります。基本的に、InProcを使用する場合、アプリプールのリサイクル時に「ライブ」であるセッションはすべて失われます。これをコンテキストに入れると、購入ファネルを実行していて、プロセスにとって重要な何かをセッションに保存している可能性があります（これが悪い習慣である理由は別の会話です）。とにかく、そのセッション情報が破損/失われた場合、ユーザーは続行できなくなります。そのため、アプリプールはリサイクルされ、現在ライブセッションが失われます。そのため、現在購入ファネルにいる顧客はドロップアウトし、失われる可能性があります。
その理由だけで、私は常にSqlServerセッションを少なくとも（ローカルでも）実行することをお勧めします。より良いアーキテクチャは、一般的にパフォーマンスの問題を打ち消します。パフォーマンスの問題が発生した場合は、サードパーティのStateServerの実装を検討する可能性があります。
ライブサーバーでInProcを実行することの欠点を読んだ後でも、それを実行できることに満足している場合（それはあなたの理由であるため、問題ありません）、私が推奨できる唯一のことは、開発サーバー（またはテスト）を実行するように変更することです。 SqlStateを使用し、LiveをInProcで実行したままにします。そうすれば、InProcを使用していない環境で問題を確認し、非稼働環境でそれらを修正できます。次に、Liveを切り替えることにした場合、追加の開発作業は必要なく、すべて問題がないことがわかります。