ゲートチェックイン時のソース管理状態 その1


このネタは凄く長いです。m(. ̄  ̄.)mス・スイマセーン

通常(ゲートチェックインなし)、修正中のソースは「保留中の変更」として管理され、チェックインが完了すると「保留中の変更」からなくなります。
・修正中

Scr000058

・チェックイン後

Scr000059

ところが、「ゲートチェックイン」を発動させると、ゲートチェックインが正常となった場合でも「保留中の変更」が変更されません。
・ゲートチェックイン正常終了後

Scr000062

この場合、ビルド完了通知の中の「ワークスペースの調整」を行うことにより正常な状態になります。
・ビルド完了通知 その1

Scr000063

「調整」ボタン押下で実行

・ビルド完了通知 その2(右下)

Scr000064

右下に表示されている「ワークスペースの調整」リンクを押下で実行

・ビルド完了通知 その3(処理ログ)

Scr000065

2行目の「ワークスペースの調整」リンクを押下で実行

・調整中

Scr000066

ほんとは自動で調整してほしいところですが、この中では「その3」が一番使えます。
→「その1」と「その2」は、ビルドが完了してから表示されるまでに数分かかりますが、「その3」はビルド完了後すぐに実行できます。

次はEclipse編です。

1つのTFSプロジェクトで、.NETとJavaの共存は可能か?

世の中一般的にあるかどうはわかりませんが、自分の部署では、Javaと.NET(正確にはNative C++ですけど)を併用することがあります。

プロジェクト管理上、Javaと.NETを別々に管理しなくない(あとでまとめる作業が発生してしまう)ので、1つのTFSプロジェクトに両方とも突っ込みたいと考えます。

今のところの結論は、
 「ゲートチェックインを使わないのであればすんなり共存可能」

です。

なんでか?というと、
まず、.NETとJavaのプロジェクトは別々に登録可能です。
ビルド定義も別々に作成可能です。
但し、「ゲートチェックイン」は複数定義が存在する状態で、
 ・.NETからのチェックインした場合は、確認画面から実行対象とするビルド定義を指定する
Scr000057
 ・Eclipseからは、確認画面なしで1つだけビルド定義が実行される
という動作になります。

Eclipseから実行されるビルド定義がJava用であればまだOKなのですが、.NET側のビルド定義が実行される可能性があるのなら使えない機能に。

と書きながら、Javaのプロジェクトが2つ以上あるときにはどう頑張っても無理?

Eclipse・TFSのプロジェクト作成時の注意点とソースコントロール設定

今回のネタは、完全にメモレベルです。

○TFS・Eclipseのプロジェクトを作成するときの注意点
 ・TFSのプロジェクト名とEclipseのプロジェクト名を一緒にしない
  TFSに登録するときにわけわからん。
 ・EclipseプロジェクトをTFSに登録する場所は、「$/[TFSプロジェクト名]」直下ではなく、「$/[TFSプロジェクト名]/[Eclipseプロジェクト名]」
  「$/[TFSプロジェクト名]」に登録すると、TFSと連動できなくなる。
 ・Eclipseのワークスペースは、全作業者で同一パスにすること

○Eclipse上でのソースコントロール
 ・ロックレベル・自動チェックアウト時の動作設定は、「プロジェクトを右クリック→チーム」ではなく、メニューの「ウィンドウ→設定(Preferences)」で表示される画面の中の「チーム→Team FoundationServer→Source Control」
 ・変更したほうがよさそうなのは、
  ・「Source Control Options」の「Get latest version of item on check out」をOnにする
  ・「Checking Out In Editors」を「Prompt before checking out files」に変更

VS IDEとEclipseでのビルド定義の違い

新しいTFS Power Toolsも触りたいですが、まずはネタを放出しないと忘れそうです。

VS IDEは当然ですが、EclipseでもTeam Explorer EverywhereをインストールするとTeam Explorerが使えます。
そこからビルド定義が作成できるのですが、VS IDEとEclipseとで定義できる内容が異なります。

VS IDEの画面は、
Scr000054
と、ビルド時のプロセスを定義できるのに対して、Eclipseの画面は
Scr000006
と、ビルド定義ファイルを作成するだけの画面になります。

詳細項目(ビルドエージェントの指定/MSBuild.exeへのパラメータ設定)はVS IDEからしか指定できないので、.NETで開発しないプロジェクトでも通常の(Everywhereではない)Team Explorerはあったほうがよい(というか必須?)と思われます。

ちなみに、ビルド定義の新規作成はEclipseから行い、詳細をVS IDEで変更するのが簡単です。

TFS Power Tools September 2010 リリース

TFSのネタの続きをしようかと思ってたら、Team Foundation Server Power Tools September 2010がリリースされたようです。

いろいろ拡張されているようなので、確認するのにも時間が掛かってしまいます。(^_^;)
今回、以下の機能が新規・拡張されてます。
 ・Alerts Explorer
 ・Team Foundation Server Backups
 ・Microsoft Team Foundation Server 2010 Best Practices Analyzer
 ・Custom Check-in Policy Pack
 ・Process Editor
 ・Team Explorer Enhancements
 ・Team Foundation Power Tool (TFPT.EXE) Tool
 ・Team Members
 ・Windows PowerShell Cmdlets for Visual Studio Team System Team Foundation Server
 ・Windows Shell Extensions
 ・Work Item Templates
ちょっとしか見れていませんが、ビックリだったのは「Process Editor」、役に立ちそうだなぁと思ったのが「Work Item Templates」です。

ちなみに、とあるところでこちらのブログにて公開されていることを知ったのですが、最後のほうに「4ヶ月ごとに更新する予定」とありました。

TFS2010 Build Extentionsのインストール その2

その1に関連したネタです。

Build Extentionsをデフォルト以外のフォルダにインストールした場合、再インストールとなるわけですが、それだけではNGな場合があります。
→ビルド時のエラーログを見ると、再インストール前のフォルダを参照しています。

この場合には、OSの環境変数を確認してください。
ひっそりと「MSBuildExtensionsPath」が定義され、その内容が再インストール前のフォルダになってることがあります。

自分の場合には、ビルドサーバが64bitだったので「MSBuildExtensionsPath」の内容を「%ProgramFiles(x86)%」に変更し、マシンを再起動したらちゃんと動作しました。
(もしかすると、「MSBuildExtensionsPath」を削除してもOKかもしれません。)

TFS2010 Build Extentionsのインストール その1

やっとTFS2010のソース管理の初歩の初歩ができるようになった気がする今日この頃。←長っ!

「こんなこと知らないの?」というレベルかもしれませんが、個人的には小ネタがそろったので放出。
「この内容おかしい(--〆)」というのがあれば、ご指摘願います。

まずは、TFS2010 Build Extentionsのインストール時の注意点について。
TFS Build Extentionsは、ビルドサーバにインストールすることで、Ant/Mavenのビルド・JUnitによる自動テストが実行てきるようになります。
→全体概要は長沢さんのブログへどうぞ。
  TFSの極意 vol.5 | Build Extensions を用いたビルドサーバーでの Ant/Maven 2 実行!Java プロジェクトでも TFS を活用。

まずはインストールしないと使えないのですが、インストール中にインストール先フォルダを指定する画面があります。

Scr000004

ここで、「デフォルトから変更してはいけない!」
というのが注意点です。
変更すると、Antのビルドで使用される「Microsoft.TeamFoundation.Build.Extensions.Ant.targets」がない!と怒られます。

ちょっと調べてみると、こんな感じでした。
・Eclipseからビルド定義を作成した場合、TFSは裏でこっそりTFSプロジェクト内に「TeamBuildTypes」というフォルダを作成し、その中にビルド定義名のサブフォルダを作成、さらに「TFSBuild.proj」というMSBuild用定義ファイルを作成しています。
Pg00006

この「TFSBuild.proj」の中で、TFSビルド機能が通常使う(と想定(^_^;))ビルド定義と、Antと連動するための定義ファイルをインポートしているところがあります。
Pg00007
(7行目の「<!– Do not edit this –>」の下2行がインポートしているところです)

このうち、「Microsoft.TeamFoundation.Build.targets」はTFS2010のインストール時に入りますが、場所は固定です。(32bit:%ProgramFiles%配下、64bit:%ProgramFiles%配下と%ProgramFiles(x86)%配下の両方)

もう一つの「Microsoft.TeamFoundation.Build.Extensions.Ant.targets」は、Build Extentionsインストール時に入りますが、場所はインストール先フォルダにより変わります。

ところが、先ほどの「TFSBuild.proj」の内容をよく見ると、フォルダ指定の先頭部分は2つとも共通で「$(MSBuildExtensionsPath)」となっています。
これが原因で、Build Extentionsのインストール先を変更すると、必ずエラーとなるわけです。
このファイルを直接編集してもいいんですが、インストール先をデフォルトのままで使用したほうが無難な気がします。

自分が環境を作るときには、
 ・スペース入りフォルダを使用したくない
 ・フォルダ名は短くしたい ← command.comの環境変数サイズの名残でつい(^_^;)
のでフォルダを変更してしまうのですが、たまには変更しないほうが良い時もあると。

TFS+Build Extentionsでビルドが実行できない環境

TechEd2010が終わってから、TFS2010をいろいろ使ってみてる今日この頃です。
最近仕事ではJavaなプロジェクトが増えてきたので、
 ・TFS2010サーバ
 ・別にビルドサーバ(2003 R2 SP2/2008 R2)を構築(+TFS Build Extensions Power Tool)
 ・クライアントはWin7でEclipse+Everywhere
という環境を作ってるのですが、ちょっと残念なことが発生。

クライアント(Eclipse)からWindows Server 2003 R2のビルドエージェントに対してビルドを実行してしばらくたつとエラー終了。ビルド結果を見ると、

E:\App\MSBuild\Microsoft\VisualStudio\v10.0\BuildExtensions\Microsoft.TeamFoundation.Build.Extensions.Ant.targets – 1 エラー、0 警告、 ログ ファイルの表示
E:\App\MSBuild\Microsoft\VisualStudio\v10.0\BuildExtensions\Microsoft.TeamFoundation.Build.Extensions.Ant.targets (208): "Microsoft.TeamFoundation.Build.Extensions.Tasks.Ant"
タスクをアセンブリ C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\BuildExtensions\Microsoft.TeamFoundation.Build.Extensions.Tasks.dll から読み込めませんでした。
ファイルまたはアセンブリ ‘file:///C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\BuildExtensions\Microsoft.TeamFoundation.Build.Extensions.Tasks.dll’、またはその依存関係の 1 つが読み込めませんでした。
指定されたファイルが見つかりません。 <UsingTask> 宣言が正しいこと、アセンブリとその依存関係が使用可能であること、および Microsoft.Build.Framework.ITask を実装するパブリック クラスがタスクに含まれていることを確認してください。

以下...(ーー゛)

参照DLL(Microsoft.TeamFoundation.Build.Extensions.Tasks.dll)はちゃんと存在しているので、依存関係かいな?ということで、Dependency Walkerで調査。
すると、「IESHIMS.DLL」と「WER.DLL」がない!!

知ってる人は知ってるこのDLL、そうです。IE8をインストールすることで参照されるDLLです。しかも、回避手段なし!
→IE8をアンインストールしようとすると、.NET Framework 4まで道連れにしようとします。
 (インストール順に関連するかもしれませんが)

.NETのビルドももしかするとNGかもしれません。
→Dependency WalkerでMSBuild.exeを見てみたら、しっかり「IESHIMS.DLL」「WER.DLL」がないと怒られました。でも、Visual Studio 2010のシステム要件に2003 R2 SP2/XP SP3が含まれているので、動くような気がします。
※一応、Windows Updateで「優先度の高い更新プログラム」は全部入っている環境ですので、Windows Updateでは解決できなさそうです。

Windows Server 2003 R2/Windows XPでビルド環境を構築するときには、IE8抜きがおすすめです。
というか、「Windows Server 2008 32bitでいいだろ!」って感じもしますが。

TFS2010とProject2010の連携

会社と家でTFS2010をいろいろ触ってみてますが、TFSなるものは2010で始めて触るので、いろいろ知らないことだらけです。

TFS2010とProject Professional2010とでは、アドオンを別途準備しなくても連動が可能になっています。

Projectを起動し、「チーム」タブに移動。

Pg00001

左端にある「チームプロジェクトの選択」を押すと、見慣れた「チーム プロジェクトへ接続」が表示されますので、TFSサーバ・コレクション・プロジェクトを指定します。

Pg00005

接続が完了すると、各種機能が使用可能になります。

Pg00006_2

タスクとかデザインレベルでのテスト項目を作成するときは、Projectを使うと全体を見ながら作成できるのでとても便利です。

メモ
 ・変更内容をTFSに保存するのは「発行」で。
 ・リソース名と作業項目の種類を指定しないとTFSに保存できない。
 ・終了時に「Project1を保存しますか?」と聞かれるが、保存する必要なし。

Team Foundation Server MSSCCI Provider April 2010をWindows XP上のVB6で使う その2

さて、続きです。

2.インストール
  .NET Framework 4→Visual Studio 2010 Team Explorer→Team Foundation Server MSSCCI Provider April 2010の順にインストールするだけです。

3.VB6の設定
  (1) まずは、TFS MSSCCI Providerのレジストリ登録です。
    コマンドプロンプトを起動し、Provider DLLが格納されているフォルダ(標準だと「C:\Program Files\Microsoft Team Foundation Server MSSCCI Provider」)に移動します。
    その後、「regsvr32 TfsMsscciProvider.dll」を実行します。
    →世の中をあさっても、「TfsMsscciProvider.dll」の名前がでてこないんですよね。
  (2) WindowsフォルダにあるVB6用アドイン設定Iniファイル(vbaddin.ini)を開き、「vbscc=3」を追加する。

これでVB6を起動すると、「ツール」メニューにTeam Foundation Serverのメニューが追加されます。

使った時の画面とかはまた今度。
→TechEd 2010参加中で、環境が見れないので。