2

私はまだこれを完全に正しく理解していないので、あまり厳しくしないでください。うまくいけば、誰かがある種のテキストのアスピリンを提供できますか? だからここに私がやりたいことがあります：

  • 複数の構成を持つ Web アプリケーション プロジェクトがあるため、複数の web.config-transforms があります。

  • このプロジェクトをコマンド ラインからデプロイしたいと思います。

  • プロジェクトファイルを変更したくありません。(いくつかのWebアプリケーションでこれを実行できるようにしたいので、できるだけ編集していただければ幸いです)

  • 一度だけビルドして、そこからさまざまな構成をデプロイできるようにしたいと考えています。

これまでのところ、次のようなものを使用してコマンドラインからデプロイしました:

msbuild D:\pathToFile\DeployVariation01.csproj
        /p:Configuration=Debug;
        Platform=AnyCpu;
        DeployOnBuild=true;
        DeployTarget=MSDeployPublish;
        MSDeployServiceURL="localhost";
        DeployIisAppPath="DeployApp/DeployThis01";
        MSDeployPublishMethod=InProc

そして、これは「デバッグ」構成のみを展開することを除いて、私が望むことを実行します。最小限の調整で、他の構成もデプロイするにはどうすればよいですか?

すべての構成を含むパッケージを作成し、そこから展開して、展開する構成を「展開中に」決定できるのではないかと考えていました。残念ながら、私はここでほとんど立ち往生しています.私が読んだすべてのアプローチは、プロジェクトファイルにいくつかの変更を加える必要があるようです.それを回避する方法はありますか?

更新：私はまだここにいたい場所にいません:)。

しかし、私はこのPackageWeb アプローチ(これに関する興味深いビデオもここにあります) を調べましたが、かなりいいようです。これで、すべての変換を含むパッケージを作成し、そこから何度でも複数の構成に展開できます。

これについて私が嫌いなことの 1 つは、powershell スクリプト用に生成されたパラメーター ファイルにパスワードをプレーン テキストで保存する必要があることです。誰かがこれを回避する方法を知っていますか?

また、私の元の問題を解決するための他のアプローチも引き続き高く評価されています。

4

1 に答える 1

0

私は同じ問題に取り組んでおり、現在バージョン 3.0 になっているMicrosoft Web Deployまたは MSDeploy を使用して 2 つの方法をとっています。

最初に、MSBUILD を使用してプロジェクトをコンパイルし、system.configuration、system.packagelocation で渡す Package ターゲットを使用します。パッケージ ターゲットは、{PackageName}.SetParameters.xml ファイルを含む一連のパッケージ ファイルを生成します。SetParameters.xml ファイルでは、既定で、msdeploy.exe を使用してファイルを公開するときに、再コンパイルせずに公開時に ConnectionStrings を変更できます。パブリッシュ変換プロセスは、parameters.xml ファイルをプロセスに追加して、デプロイ時に変更できる追加のパラメーター化された web.config 設定を定義することによってカスタマイズすることもできます。

最初のビルドの後、パッケージ プロセス中に MSBUILD によって生成された {PackageName}.deploy.cmd ファイルを使用して、パッケージを対象の Web サイトにデプロイします。パッケージ プロセスは、1 つのコンパイルから 1 つの Build-Configuration web.config 変換を発行できるという点で、MSBUILD から現在実行しているプロセスを基本的に複製します。このプロセスは、中央の CI 環境からリモート サーバーを対象とすることができる一貫した展開プロセスを提供します。これは、純粋な展開プロセスから優れています。PackageBuild/Deploy プロセスは TeamCity 内でパラメーター化され、新しいデプロイをセットアップするためにいくつかのパラメーターを変更するだけで済みます。

ただし、あなたと同じように、単一バージョンのコードをコンパイルし、現在のプロセスを使用して複数のサーバーに展開することはできません。これが現在の焦点です。開発、QA、ユーザー テスト、ステージング、および運用への継続的展開、ビルド ワンス デプロイ マニー パターンの変換をパラメーター化したいと考えています。

次の 2 つの方法のいずれかを使用する予定です。

  1. 各ターゲット展開のカスタム {ServerName}.SetParameters.xml と共に可変展開パラメーターを定義するプロジェクトごとに Parameters.xml ファイルを作成します。両方とも msdeploy.exe と組み合わせて使用​​します。を。現在のプロジェクトは可変数の web.config 設定を挿入および削除するため、parameters.xml を定義することが私のニーズに十分柔軟なプロセスであるかどうかはわかりません。すべての変数を組み込んだパラメーター ファイルを実装するのは、私の好みでは複雑すぎるかもしれません。また、現在の開発者が開始したプロセスではなく、すべてのターゲット変換を作成することになります。理想的ではありません。

  2. 私は、VS2012 の SolutionName/Properties/PublishProfiles に保存されている発行プロファイル (profile.pubxml) に web.config 変換を関連付けることができる VS2012 Web Tools 2012.2 のごく最近の更新をフォローアップしています。

VS2012 リリース 2012.2 では、発行プロファイルに関連付けられた 2 番目の変換を作成する機能が追加されています。結果として得られる変換プロセスでは、最初にビルド構成の変換が実行され、その後に発行の変換が実行されます。つまり、Release Transform の後に TargetServer Transform が続きます。Sayed Hashimi は、MSBUILD を使用したプロセス全体を示すすばらしいYouTube ビデオを公開しています。

完全に明確ではないのは、2 番目の変換が MSDeploy を使用したビルドとは別にサポートされているかどうかです。これは、継続的配置、build-once-deploy-many パターンで実行されるか、または発行変換がターゲット変換ごとに個別のパッケージ/ビルド中にのみサポートされるかどうかです。 .

オプション 1 は、一部の環境では確実に機能し、継続的デプロイ プロセスに取り組むための最初の計画でした。可能であれば、Web Transforms を使用してプロセスを実行したいと考えています。

外部の 3 番目の可能性は、XDT 変換エンジンを使用して web.config を変換できるいくつかの CodePlex コマンドライン プロジェクトの 1 つを使用することです。残念ながら、これらのツールを使用すると、結果をビルド/パッケージ MSBUILD プロセスにつなぎ合わせて、結果の web.config 変換を展開パッケージに変換することになりますが、これはまだ成功していません。Sayed Hashimi には、2012 年の PackageWeb プロジェクトもあり、これも同様に機能する可能性があります。彼の最近の作業が、packageweb ソリューションに含まれる余分な手順の必要性に取って代わることを願っています。

解決策が決まったら教えてください - 私は間違いなく興味があります。

于 2013-05-09T22:38:28.133 に答える