33

ソリューション構成を環境にマッピングし、環境ごとのパッケージ化にMsDeployを使用するための適切なパターンはありますか？

最短バージョン：このファイルを取得し、パッケージが作成されるように.msbuildファイルを変更してみてください。

詳細

多数のライブラリとASP.NETMVCアプリケーションを使用したソリューションがあります。メインソリューションを呼び出してから他のことを行うmsbuildファイルを使用してビルドを駆動します。新しいmsdeployパッケージを使用して、後で配布するために.zipファイルを準備したいのですが、さまざまな問題が発生しています。

私のソリューションには、マップする環境に一致する、、、、およびの4つLocalの構成があります。そのソリューションでは、すべてのライブラリに通常のモードがあります。たとえば、ソリューションモードでは、すべてのライブラリがモードでコンパイルされます。次に、メインアプリケーションはソリューションと一致する環境を持っているので、私はそれを行うことができます。これは、物事を使用する自然な方法のようです。DevTestProdDebugReleaseLocalDebugWeb.Dev.config

このようにパッケージ化した場合：

<Target Name="BuildWebPackage">
  <MSBuild Projects="..\Publisher\Site\Site.vbproj"
           Targets="Package"/>
</Target>

Configuration=Localが参照するライブラリプロジェクトに誤ってマップされ、Site.vbprojそれらをコンパイルできないという問題が発生します。

考えられる解決策は2つあります。1つは正しく機能しないこと、もう1つは非常に醜いことです。

試行1

ソリューションを介してターゲットを呼び出そうとしますPackage（この例では、「アプリケーション」はサイトプロジェクトが含まれるソリューションフォルダーです...ソリューションには実際には複数のアプリケーションがあるため、この投稿では物事を簡略化しました）。

<Target Name="BuildWebPackage">
  <MSBuild Projects="..\Publisher\Publisher.sln"
           Targets="Applications\Site:Package"/>
</Target>

SolutionFolder\ProjectName:Target実行されるので、この構文はこれを行う方法だと思います:Clean...しかし、これはスローします

error MSB4057: The target "Applications\Site:Package" does not exist in the project.

試行2

醜いソリューションの場合：すべてのライブラリを変更して、これら4つのソリューション構成に対して4つの追加構成を設定すると機能します。ただし、後で異なる環境を持つプロジェクトと共有ライブラリを共同開発したい場合、これは醜くて本当に悪い計画です。また、これらの環境はライブラリとは関係がなく、ライブラリを使用するトップレベルのアプリケーションのコンテキストでのみ意味があります。味が悪い。

は？

Package私はソリューションに複数の環境があり、新しいWeb.configの置き換えが好きですが、この状況でmsdeployタスクを呼び出す方法がわからないため、TeamCityでパッケージをビルドできます。

（msdeployコマンドラインはIISアプリをパッケージに変換するために使用されるため、おそらく呼び出したくないことに注意してください。ここで行っていることではありません。）

サンプル

繰り返しになりますが、私はここで完全に困惑しているので、実験を手伝いたい場合は、このサンプルソリューションをまとめました。

4

2 に答える 2

40

パッケージターゲットがソリューションファイルに存在しないため、最初の試行は失敗しました。ソリューションファイルでMSBuildを使用すると、一時的なMSBuildプロジェクトが作成されます（SamplePackage.sln.metaproj）。このプロジェクトファイルには、一部のターゲット（Build、Clean、Rebuild、Publish、...）のみが含まれています。

解決策：DeployOnBuildおよびDeployTargetプロパティ

必要なことを行う1つの方法は、次のようなDeployOnBuildプロパティを使用することです。

<PropertyGroup Condition="'$(Configuration)' == ''">
  <Platform>Any Cpu</Platform>
  <Configuration>Dev</Configuration>
  <PackageLocation>$(MSBuildProjectDirectory)\package.zip</PackageLocation>
</PropertyGroup>

<Target Name="Build">
  <MSBuild Projects="SamplePackage.sln"
           Targets="Build"/>
</Target>

<Target Name="BuildWebPackage">
  <MSBuild Projects="SamplePackage.sln"
           Properties="Platform=$(Platform);
                       Configuration=$(Configuration);
                       DeployOnBuild=true;
                       DeployTarget=Package;
                       PackageLocation=$(PackageLocation);"/>
</Target>
  • DeployOnBuild = true：ビルドが呼び出されたときにデプロイを行う必要があります
  • DeployTarget = Package：デプロイメント用にパッケージを作成します
  • PackageLocation：パッケージファイルのファイルパスを示します

追加のリンク：

于 2010-08-24T21:06:44.980 に答える
0

私は役に立つかもしれない同様のことをしました。最近のプロジェクトでは、「Dev」、「Test」、「Prod」の環境がありました。

これらのそれぞれにソリューション構成を追加しました。

  • リリース-開発
  • リリーステスト
  • リリース-製品

ソリューション内のほとんどのプロジェクトでは、これらの構成は通常の「リリース」ビルドにリンクされていましたが、適切な場合、一部のプロジェクトには、コードに＃if /＃endifが含まれる可能性のある別個の「リリース-テスト」ビルド構成がありました。

これは、構成ごとにmsdeploy構成をカスタマイズできるようにすることにも意味があります。

msbuildターゲットについて。ターゲットは要素の名前を参照します。たとえば、上記の例では、/ t：BuildWebPackageを使用してmsbuildを呼び出すことができます。

于 2010-08-20T06:59:51.300 に答える