5

私は継続的インテグレーションプロジェクトの次のステップに取り組んでいます。それは、TeamCityにアプリケーションをビルドさせ、すべてのアセンブリのバージョン番号を自動的に変更してから、インストーラーを作成することです。

最初に少し背景：

私は過去数か月間TeamCityを正常に実行しており、構成を構築し、NUnitテストとNCoverテストを正常に実行しています。

私はインストーラーの調査に少し時間をかけました-私は常にInstallShieldを嫌い、現在のアプリケーションではそれを考慮していませんでした。私はNSISが好きですが、たまたまWiXに出くわしました。複雑なプロジェクトでは危険であると理解しているMSインストーラアーキテクチャについての深い知識がないので、ある時点でそれについてさらに学ぶ必要があります。しかし、SOの質問、グーグル、ブログの閲覧を数日間行った後、WiXプロジェクトが正常にビルド、インストール、アプリケーションの実行、すべてが正常にアンインストールされました。素晴らしい！

また、TeamCityビルド構成で、すべてのアセンブリのバージョン番号を自動的に更新する必要がありました。開発マシンにMSBuildコミュニティタスクをインストールし、 BeforeBuildターゲットとFileUpdateタスクを使用してバージョン番号を変更する展開構成を作成することで、この機能をモックアップすることができました。これは適切に機能しますが、開発マシンには、置き換えるbuild_vcs_number_1環境変数がありません。

これが私が今いる場所です。TeamCityに更新を行わせる必要があります。build_vcs_number_1環境変数はありますが、WiXMSBuildコミュニティタスクを取得する方法がわかりません。

私が読んだある投稿では、MSBuildターゲットをSVNフォルダーにチェックインすることをお勧めします。このようなもののための/extlibフォルダーがあるので、TeamCityVCSチェックアウトルールは次のようになります。

+:tags/2010-10-15=>src
+:extlib=>extlib

環境変数からextlibにアクセスするにはどうすればよいですか？ ビルドを実行すると、TeamCityはが見つからないと文句を言います（正しくはそうです）c:\wix30\MSBuildCommunityTasks。実際のフォルダはC:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasksです。サーバー側のチェックアウトを実行しているため、フォルダーは自動生成されます。そのため、正しいパスを取得するために使用できるTeamCityが設定する環境変数が必要です。

注意すべき点の1つは、ビルド構成->プロパティと環境変数に移動し、既存のすべての変数を含む直感的でないドロップリストを見つけましたが、作業パスを指す変数のように聞こえるものは何も表示されなかったことです。

考えられる回避策の1つは、ビルドサーバーにMSBuild Community Tasksをインストールするだけで、からアクセスできるシステム環境変数を作成できます<WixToolPath>。

他に何か提案はありますか？

4

2 に答える 2

1

（ビルドマシンの要件を減らすために）SVNでmsbuildコミュニティタスクを実行しようとすることにはいくつかのメリットがありますが、個人的にはサーバーにインストールするだけです。重要な部分：ビルドサーバーのドキュメントを更新して、それを前提条件としてインストールすることをリストします。私の場合、基本的にいくつかのプロジェクトのすべてのmsbuildでコミュニティタスクとデプロ​​イメントスクリプトを使用しているため、それらすべてをSVNに保持するのは少し冗長です。ビルドサーバーにもWiXをインストールしています。

私は似たようなことをしますが、ビルド前のターゲットではなく、おおよそ次のようなmsbuildプロジェクトファイルがあります。

<Target Name="Build">
    <CallTarget Targets="UpdateVersionNumbers"/>
    <MSBuild Projects="Project.sln" Targets="Build"/>
</Target>

私のUpdateVersionNumbersターゲットはSVNリビジョンを取得し、正規表現とFileUpdateタスクを使用して、バージョン番号の4番目の部分をSVNリビジョンに変更します。

次に、ソリューションファイルの通常のビルドを実行し、それに含まれて.wixprojをビルドします。とてもシンプルです。

ただし、他の質問のいくつかに答えるには：

  • パスを指定するときは、常にソリューションのルート（チェックアウトディレクトリ）を基準にしたパスを使用してください。したがって、たとえばこの場合は、を使用するだけwix30\MSBuildCommunityTasksです。TeamCityは、作業ディレクトリをルートとしてmsbuildを実行します。さらに、あなたや他の開発者がどこにチェックアウトするかは関係ありません。パスはすべて相対的なものです。

  • [ビルドパラメーター]->[システムプロパティ]を使用して、teamcityのパラメーターをmsbuildに渡すことができます。たとえば、agentHomeの値を持つというプロパティを追加する%system.agent.home.dir%と、msbuildファイルで$（agentHome）として参照できます。上記の例のようにmsbuildも再度呼び出す場合は、次のことを行う必要があります。

      <MSBuild Projects="Project.sln" Properties="agentHome=$(agentHome)" Targets="Build"/>

    その変数を実際にProject.slnに渡します。と思いますが、.slnファイルで実行されているmsbuildがすべてのプロパティをすべての個々のプロジェクトに渡すので、ビルド前のイベントで実際にアクセスできるとは思いません。

インストーラーに関する補足（私は最近あなたがしたのと同じことを経験しました）：私はWiX 3.0に落ち着きました、そしてそれにはかなりの学習曲線がありますが、それはうまくいきます。新しい開発ストリームを開始し、VS2010と.NET 4の使用を開始しました。WiX3.0はVS2010と互換性がないため、WiX 3.5（まだベータ版ですが、現在の状態はそれよりもはるかに良いようです）が必要でした。数ヶ月前でしたが、まだ遅れています。これがオープンソースの性質である場合もあります）。WiX 3.0と3.5を一緒にインストールするのに少し苦労しましたが、ついにそれを理解しました。

しかし、これに対する欲求不満（非互換性、不安定なベータ版（数か月前から）、および全体的な遅い進行の間）は、実際にWiXをオフにしました（WiXで作業している人には不快感はありませんが、インストーラーが必要です。それを巻き込みたいのです。彼らも非常にイライラしていることに注意してください）。それに加えて、次に必要な製品にはもっと複雑なインストーラーが必要であり、WiXは非常に手間がかかるようです。AdvancedInstallerを使用してインストーラーを構築したところ、数日しかかからず、これまでのところうまく機能しています（ただし、現在は開発の初期段階にありますが、継続的な展開とテストを開始しています）。AIの価格はリーズナブルですが（現在はまだ試用版です）、数日中に購入する予定です。

AIの学習に費やした時間は、WiXの学習に費やした時間よりもはるかに短く、必要なことをすべて実行できるようにしようとしたことは確かです。Windowsインストーラーがどのように機能するかについて何かを学ぶことは少し避けられませんが、あまり深く理解する必要はありません。

于 2010-10-27T04:36:13.337 に答える
0

これが起こったとき、私はそれを嫌います...長い質問を入力してください、数分後に私が逃した何かを見つけるためだけに。

いつも夢みてかしら：

代替テキスト

私の質問は今だと思います-.wixprojで実際に％system.agent.work.dir％を使用できますか？今からやってみます。

于 2010-10-27T04:11:15.140 に答える