1

Hanselman が彼のTiny Happy Features #3で言及したように、また他の多くの場所で推奨されるアプローチと考えられるものとして言及したように、デプロイを行うために次のビルド ターゲットを設定しました。

msbuild my_web_application.csproj /p:Configuration=Production;
                                     DeployOnBuild=true;
                                     PublishProfile=Production;
                                     VisualStudioVersion=11.0;
                                     AllowUntrustedCertificate=true;
                                     AuthType=NTLM

これでうまくいき、コマンド ラインで ms deploy を呼び出して以前行っていた展開手順が置き換えられます。

msdeploy.exe" -source:package="c:\source_to_my_web_application.zip" -dest:auto,my_server_name,includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"c:\source_to_my_web_application\Package.SetParameters.xml"

2 つの方法の最大の違いは、コマンド ライン呼び出しでは変更のあるファイルのみがプッシュされるのに対し、msbuild 呼び出しでは毎回 Web アプリケーション全体が送信されることです。

msdeploy への直接呼び出しが私のために行ったように、msbuild バージョンに「同期」動作をさせる方法はありますか?

4

1 に答える 1

0

私が確立できたことから、パッケージ (この特定の MSBuild コマンド用に作成されたものなど) から同期すると、展開しようとしているローカルの作業コピーに関連する違いが見つかります。

新たにチェックアウトしてからビルドしてデプロイすると、Web アプリケーション全体が公開されます。

その作業コピーをクリーンアップして再構築すると、再構築された dll のみが公開されます。

その上でビルドを行うと、変換された web.config ファイルと、韻を踏んだり推論したりできないその他のランダムな dll のみが公開されます。

要するに、私たちの CI サーバーのセットアップでは、すべてのファイルがサーバーに公開されると想定する必要があり、公開されるファイルがそれよりも少ない場合は、帯域幅のボーナスです。

補足として、通常の ms deploy コマンドを実行しているときに、ランダムで信頼性の低い 404 エラーも発生しました。それらは断続的であるように見え、MS Deploy サービスが 404 を返すか、連続する各呼び出しの数秒以内に正常に実行されるように、自分のワークステーション、同僚、および CI サーバーの間で異なる可能性があります。このタイプの動作に対して私が見つけた解決策は、Visual Studio の再起動から、さまざまなコンポーネントのアンインストールと再インストールまで、正しい順序で実行し、「ary」で終わる月の第 3 週の第 2 火曜日だけに実行することです。 ..

私にとって重要なことは、このツールは大雑把であり、ある程度の信頼性で動作するようにセットアップできる場合、それは奇跡であり、二度と触れず、シリコンの神々にその状態が維持されることを祈るべきだということです.

于 2013-04-03T18:44:46.500 に答える