私は.net 3.5の新しいプロジェクトに取り組んでいます。
現在、クライアントはストアド プロシージャを使用しており、代わりに LINQ to SQL を使用したいと考えています。彼らがストアド プロシージャを使用する主な理由は、更新が簡単であると信じているためです。特別なアクセス許可を使用していないなど、変更したくないだけで LINQ to SQL 経由でストアド プロシージャを使用することを正当化できます。
LINQ to SQL への変更を簡単に展開できるソリューションを彼らに提示できれば、彼らは考えを変えることにもっとオープンになるかもしれません。
そのため、ビルドプロセス中に作成されるさまざまなアセンブリを更新する方法について、asp.net プロジェクト (mvc ではない) に興味があります。
たとえば、すべての LINQ コードが System.DataAccess プロジェクトにあり、それが運用環境にデプロイされると、製品のバグが LINQ で識別されます。変更された DataAccess プロジェクト (または、prod のデプロイ以降に大幅な変更が加えられたプロジェクト) をデプロイするだけでどれだけ難しいか。
状況に役立つかどうかわからないことの1つは、実際に変更があったかどうかに関係なく、ビルドがあるたびにすべてのプロジェクトでビルド番号が更新されるため、プロジェクトのバージョン番号を見るだけで再デプロイが必要なプロジェクトを決定するのに十分ではありません。
ビルドを変更できるかどうかさえわからないので、変更されたプロジェクトのバージョンだけが更新されますか?
したがって、基本的には、そこにあるさまざまなパッチ適用プロセスと、長所と短所 (つまり、iis のリセットが必要など) に興味があります。
乾杯