すべてのバージョン履歴 (AssemblyInfo.vb) はまったく同じですが、コードのマイナーな変更が行われたという唯一の違いがある場合、アセンブリをそれ自体の更新されたバージョンに置き換える (コピー + 貼り付け) ことが 100% 安全であるかどうかを知っている人はいますか? aspx.vb ファイルの 1 つにあります。
2 に答える
既存のコードを壊していないことが確実であれば安全です (メソッドはもう存在しません...)。アセンブリを手動で読み込む場合は、必ずバージョンとトークンを更新してください。
Web サイトを別のフォルダーに複製できるかどうかわからない場合は、テスト IIS インスタンスを作成し、単一ファイルの展開をテストします。
細心の注意を払わないと重大な変更が発生する可能性がある単一ファイルの展開よりも、クリーンな展開が安全であることに注意してください。これは、テスト インスタンスでは問題にならない可能性がありますが、ライブでは決して実行しないでください。
それは間違いなく可能であり、非常に簡単に実行できますが、運用システムが非常に大規模になり、不安定になる可能性があり、多数のユーザーがいる場合、悪影響を与える可能性のある習慣になりがちです。
私が試してみること、または注意することをお勧めする方法がいくつかあります。
ソリューション内のプロジェクトに応じて、1 つまたは複数のインストーラーを作成します。これらのインストーラーは、運用サーバーにインストールする実行可能ファイルを生成します。これは手動で行います。ロールバックのために以前のインストーラーをバックアップします。
ClickOnceアプリケーションを作成できます。これは手動で実行することも、安定したスケジュール アプリを使用してスケジュールすることもできます。
Visual Studio の公開機能を利用することもできます。コードをコンパイルしてリリース モードに設定すると、ファイル/ネットワーク/ftp 経由で運用環境に公開されます。これにより、すべてのマークアップ ファイルとアセンブリが置き換えられます。
TFS Builder サーバーを使用して、毎日または毎週のビルドをスケジュールできるプロセスを自動化します。これらのインストールは手動で行うことも、SMS (Microsoft System Management Services) を使用してタイムリーなインストールをスケジュールすることもできます。
Windows Powershellも使用できます
もちろん、TFS Build Server と SMS にはコストがかかりますが、運用環境の問題によって会社がダウンする可能性がある場合、支払う代償はわずかです。
これを行うにはいくつかの方法があります。本番環境に関しては、何がうまくいくかを確認し、良い習慣を身につけてください