素人なもんでスレッドプログラミングを理解してない。
という事で下記ページで勉強。
■Visual Basic .NET でのマルチスレッド プログラミング
http://www.microsoft.com/japan/msdn/vs/vb/vbtchAsyncProcVB.aspx
2007/02/27
2007/02/23
IT業界を読み解くための経営分析入門
だんだんリンクメモになっているが。。。
■IT業界を読み解くための経営分析入門
http://itpro.nikkeibp.co.jp/members/bn/mokuji.jsp?OFFSET=0&MAXCNT=20&TOP_ID=233114&ST=start
技術的な側面ばかりがクローズアップされるIT業界だが、所詮は企業経営のもとに成り立っているわけで。そこを知る必要があると思いながらも勉強できなかったのだが、なかなかよいサイトを発見。
何よりITと経営がリンクしてる所がよい。
週末にでも読むかな。
■IT業界を読み解くための経営分析入門
http://itpro.nikkeibp.co.jp/members/bn/mokuji.jsp?OFFSET=0&MAXCNT=20&TOP_ID=233114&ST=start
技術的な側面ばかりがクローズアップされるIT業界だが、所詮は企業経営のもとに成り立っているわけで。そこを知る必要があると思いながらも勉強できなかったのだが、なかなかよいサイトを発見。
何よりITと経営がリンクしてる所がよい。
週末にでも読むかな。
System.Transactions
友人S君より教えてもらった内容。
.NET 2.0よりトランザクションモデルが強化されたようだ。
これは必見!
■10 行でズバリ !! TransactionScope の利用 (C#)
http://www.microsoft.com/japan/msdn/thisweek/300x10/phase3/Transaction_Scope/cs.aspx
■.NET Framework 2.0 の System.Transactions について
http://www.microsoft.com/japan/msdn/net/general/introsystemtransact.aspx
.NET 2.0よりトランザクションモデルが強化されたようだ。
これは必見!
■10 行でズバリ !! TransactionScope の利用 (C#)
http://www.microsoft.com/japan/msdn/thisweek/300x10/phase3/Transaction_Scope/cs.aspx
■.NET Framework 2.0 の System.Transactions について
http://www.microsoft.com/japan/msdn/net/general/introsystemtransact.aspx
2007/02/22
XMLマスター:ベーシック 実力養成講座
■XMLマスター:ベーシック 実力養成講座
http://itpro.nikkeibp.co.jp/article/COLUMN/20060928/249315/?ST=start
今年の目標として、XMLマスターベーシックに合格したいと思って勉強中。
.NETでDataSetとか扱っている割に、XMLの事を殆どわかってないような気がする。
資格取得にチャレンジする事で知識を身につけていきたい。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060928/249315/?ST=start
今年の目標として、XMLマスターベーシックに合格したいと思って勉強中。
.NETでDataSetとか扱っている割に、XMLの事を殆どわかってないような気がする。
資格取得にチャレンジする事で知識を身につけていきたい。
2007/02/21
アプリケーション構成ファイルの設定
複数人で開発するにあたり、若干手間になるのがアプリケーション構成ファイルの設定。
「appSettings」にはアプリケーション依存の値が多数設定される。
しかし各開発者の環境でその設定内容が必ずしも同期が取れるものではない。
(例えばログ出力先のディレクトリ設定など)
そこで以下のように定義するとその問題が解決するらしい。
--------------
<appSettings file="user.config">
--------------
こうするとuser.configの内容でappSettingsの設定内容を論理的に上書きしてくれるらしい。
アプリケーションから見ると設定KEYが重複している場合、「user.config」の値を正としてくれる。
これで今まで困っていた事が解決。
アプリケーション構成ファイルについては、勉強不足なので体系化する必要あり。
しかし、後輩M君。知ってるんなら教えてくれればいいのに・・・。
「appSettings」にはアプリケーション依存の値が多数設定される。
しかし各開発者の環境でその設定内容が必ずしも同期が取れるものではない。
(例えばログ出力先のディレクトリ設定など)
そこで以下のように定義するとその問題が解決するらしい。
--------------
<appSettings file="user.config">
--------------
こうするとuser.configの内容でappSettingsの設定内容を論理的に上書きしてくれるらしい。
アプリケーションから見ると設定KEYが重複している場合、「user.config」の値を正としてくれる。
これで今まで困っていた事が解決。
アプリケーション構成ファイルについては、勉強不足なので体系化する必要あり。
しかし、後輩M君。知ってるんなら教えてくれればいいのに・・・。
2007/02/14
VSTSで提供される注目すべき単体テスト機能
とある友人S君より教えてもらったのでメモ。
■VSTSで提供される注目すべき単体テスト機能
http://www.atmarkit.co.jp/fdotnet/vststester/vststester03/vststester03_01.html
なんとか記事の内容が理解できた・・・くぅ・・。
「データドリブン単体テスト」とは「データソース内の各行に対して繰り返し実行が行われる単体テスト」の事。テスト対象メソッドのパラメータ値がキューできて繰り返し実行なんて事もできる。これによって、テストメソッドの分割や、テストメソッド内のループコードが不要になるののでGoodですね。
ただ、TestContextのDataSourceがDB上のテーブルという仕様はどーなんでしょ。それはそれでOKとしても、個人的には「DataSet+データ(XML)」が設定できて欲しい所。(その方がテストリソースを一元管理できるし、DB環境もいらないし。)
わざわざDBを使用する意味が何かあるのだろうけど。
「ASP.NET単体テスト」は評価してみたい所。
個人的にBoundaryのテストコード(HttpUnit等)を試した事がないし。
■VSTSで提供される注目すべき単体テスト機能
http://www.atmarkit.co.jp/fdotnet/vststester/vststester03/vststester03_01.html
なんとか記事の内容が理解できた・・・くぅ・・。
「データドリブン単体テスト」とは「データソース内の各行に対して繰り返し実行が行われる単体テスト」の事。テスト対象メソッドのパラメータ値がキューできて繰り返し実行なんて事もできる。これによって、テストメソッドの分割や、テストメソッド内のループコードが不要になるののでGoodですね。
ただ、TestContextのDataSourceがDB上のテーブルという仕様はどーなんでしょ。それはそれでOKとしても、個人的には「DataSet+データ(XML)」が設定できて欲しい所。(その方がテストリソースを一元管理できるし、DB環境もいらないし。)
わざわざDBを使用する意味が何かあるのだろうけど。
「ASP.NET単体テスト」は評価してみたい所。
個人的にBoundaryのテストコード(HttpUnit等)を試した事がないし。
オープンソースのライセンス
今までイマイチ理解していなかったのでメモ。
基本的に以下の4つに分類されるらしい。
(1)BSD
⇒無償。コードを改変したものを再配布可。著作権表示が条件。
Apache、FreeBSD、PostgreSQLなどが利用
(2)LGPL
⇒無償。再配布可だが、ソースコードを改変した場合はLGPL/GPL下で開示。
他のソースコードからリンクした場合に、リンクする側にLGPLを適用する必要はない。
OpenOffice.org、JBossなどが利用
(3)GPL
⇒無償。改変や再配布は自由だが、GPLライセンス下でコードを開示しなければならない。
Linux、MySQLなどが利用。
(4)その他
⇒Open Source Initiativeの定義を満たすものは多いが、よく利用されているとは限らない。
詳細はさまざまであることから、条項を確認する必要がある。
Apple Public Source LicenseやSUN PUBLIC LICENSE PUBLIC LICENSEなど。
基本的に以下の4つに分類されるらしい。
(1)BSD
⇒無償。コードを改変したものを再配布可。著作権表示が条件。
Apache、FreeBSD、PostgreSQLなどが利用
(2)LGPL
⇒無償。再配布可だが、ソースコードを改変した場合はLGPL/GPL下で開示。
他のソースコードからリンクした場合に、リンクする側にLGPLを適用する必要はない。
OpenOffice.org、JBossなどが利用
(3)GPL
⇒無償。改変や再配布は自由だが、GPLライセンス下でコードを開示しなければならない。
Linux、MySQLなどが利用。
(4)その他
⇒Open Source Initiativeの定義を満たすものは多いが、よく利用されているとは限らない。
詳細はさまざまであることから、条項を確認する必要がある。
Apple Public Source LicenseやSUN PUBLIC LICENSE PUBLIC LICENSEなど。
2007/02/13
ASP.NET AJAX ファーストルック
@ITにあったのでメモ。
■特集 ASP.NET AJAX ファーストルック -ASP.NETアプリケーションをプログラミングなしでAjax化-
http://www.atmarkit.co.jp/fdotnet/special/aspajax/aspajax_01.html
ユーザーから見るとリッチクライアントは有益だが、実装者にはちと辛い感じを受ける。
ごちゃごちゃするのであまりやりたくないのが正直な所。
とは言うものの、Ajaxの波が地方にもやってきそうだ・・・(もう来てるか?)
概要は理解したつもりだが、何処までできるかを把握しておく必要があるな。
忙しいけど何とか一読の必要あり。
■特集 ASP.NET AJAX ファーストルック -ASP.NETアプリケーションをプログラミングなしでAjax化-
http://www.atmarkit.co.jp/fdotnet/special/aspajax/aspajax_01.html
ユーザーから見るとリッチクライアントは有益だが、実装者にはちと辛い感じを受ける。
ごちゃごちゃするのであまりやりたくないのが正直な所。
とは言うものの、Ajaxの波が地方にもやってきそうだ・・・(もう来てるか?)
概要は理解したつもりだが、何処までできるかを把握しておく必要があるな。
忙しいけど何とか一読の必要あり。
2007/02/09
.NETのメモリ管理
勉強すべきサイトを見つけたのでメモ。
■ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part I
http://www.microsoft.com/japan/msdn/net/mag00/GCI.aspx
■ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part II
http://www.microsoft.com/japan/msdn/net/mag00/GCI2.aspx
■マネージ コードでのメモリ リークの識別と回避
http://msdn.microsoft.com/msdnmag/issues/07/01/ManagedLeaks/default.aspx?loc=jp
最新.NETで大量データを扱うシステム構築に携わる事が多く、いい加減.NETのメモリ管理について一旦整理しとかんといかんと思っている最中。3流にはなかなか習得できないかもしれんが頑張ってみよう。
■ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part I
http://www.microsoft.com/japan/msdn/net/mag00/GCI.aspx
■ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part II
http://www.microsoft.com/japan/msdn/net/mag00/GCI2.aspx
■マネージ コードでのメモリ リークの識別と回避
http://msdn.microsoft.com/msdnmag/issues/07/01/ManagedLeaks/default.aspx?loc=jp
最新.NETで大量データを扱うシステム構築に携わる事が多く、いい加減.NETのメモリ管理について一旦整理しとかんといかんと思っている最中。3流にはなかなか習得できないかもしれんが頑張ってみよう。
2007/02/07
S2Unit.NET 体験編2 トランザクションの自動制御
更に使い込んでみて思ったのだが。
S2Unit.NETの「トランザクションの自動制御」機能ってどういうケースで利用するのだろう。
というのも。
テスト対象メソッド(以下、TestTarget)がBusinessLogic層だと仮定した場合、
通常RDBMSとのやりとりは外部から見ると隠蔽されているような設計になっている。
S2Unit.NETでこのTestTargetのTestCaseを実装する場合において、
S2Unit.NETとTestTargetのRDBMSへのセッションは別物になる。
よって以下のようにTestCaseを実装した場合、TestTargetではS2Unit.NETにて投入されたテストデータが参照できない(Commitされていないから)為、テスト自体が破綻してしまう。
<Test(), S2(Tx.Rollback)> _
Public Sub Test
' テストデータ投入
' TestTarget実行
↑※S2Unit.NETとは別セッションなのでTestTargetはテストデータが見えない
' 実行結果取得
' Assert
End Sub
と書きながら気づいたのだが。
S2Unit.NETの機能を利用する場合、アプリ側もS2Unit.NETを意識した実装を行っておくべきなのだろう。具体的にいうとTestCaseで特化オブジェクトを実装できるようアプリ側を設計する必要があるという事だ。
(アプリ側のDataSourceの生成についてはオーバーライド可能なファクトリーメソッドとして実装すべきで、TestCaseにてこのメソッドをオーバーライドしS2Unit.NETのDataSourceを使える様にしておくべきなのだ。)
まさに先日Mockについて勉強した内容だ・・・。
と、気づいた時には既に遅いのでアドホック対応をしてみた。
TestCase内でS2Unit.NETが保持するトランザクションを手動で制御するようにした。
(1)TestCaseのS2属性の引数にTx.NotSupportedを渡す(無しでもよい)
(2)MyBase.Connection.BeginTransaction
(3)テストデータ投入
(4)MyBase.Connection.BeginTransaction.Commit
(5)TestTargetを実行
(6)期待値取得
(7)実行結果取得
(8)MyBase.Connection.BeginTransaction
(9)投入したテストデータの削除
(10)MyBase.Connection.BeginTransaction.Commit
(11)Asset
S2Unit.NETの「トランザクションの自動制御」機能ってどういうケースで利用するのだろう。
というのも。
テスト対象メソッド(以下、TestTarget)がBusinessLogic層だと仮定した場合、
通常RDBMSとのやりとりは外部から見ると隠蔽されているような設計になっている。
S2Unit.NETでこのTestTargetのTestCaseを実装する場合において、
S2Unit.NETとTestTargetのRDBMSへのセッションは別物になる。
よって以下のようにTestCaseを実装した場合、TestTargetではS2Unit.NETにて投入されたテストデータが参照できない(Commitされていないから)為、テスト自体が破綻してしまう。
<Test(), S2(Tx.Rollback)> _
Public Sub Test
' テストデータ投入
' TestTarget実行
↑※S2Unit.NETとは別セッションなのでTestTargetはテストデータが見えない
' 実行結果取得
' Assert
End Sub
と書きながら気づいたのだが。
S2Unit.NETの機能を利用する場合、アプリ側もS2Unit.NETを意識した実装を行っておくべきなのだろう。具体的にいうとTestCaseで特化オブジェクトを実装できるようアプリ側を設計する必要があるという事だ。
(アプリ側のDataSourceの生成についてはオーバーライド可能なファクトリーメソッドとして実装すべきで、TestCaseにてこのメソッドをオーバーライドしS2Unit.NETのDataSourceを使える様にしておくべきなのだ。)
まさに先日Mockについて勉強した内容だ・・・。
と、気づいた時には既に遅いのでアドホック対応をしてみた。
TestCase内でS2Unit.NETが保持するトランザクションを手動で制御するようにした。
(1)TestCaseのS2属性の引数にTx.NotSupportedを渡す(無しでもよい)
(2)MyBase.Connection.BeginTransaction
(3)テストデータ投入
(4)MyBase.Connection.BeginTransaction.Commit
(5)TestTargetを実行
(6)期待値取得
(7)実行結果取得
(8)MyBase.Connection.BeginTransaction
(9)投入したテストデータの削除
(10)MyBase.Connection.BeginTransaction.Commit
(11)Asset
2007/02/05
Mock 体験編
うーむ。以下の理解であってるだろうか・・・。
■言葉の定義
Mockを使うにあたっては以下の役割を持つオブジェクトが存在する
(1)ターゲットオブジェクト
⇒テスト対象オブジェクト
(2)コラボレーターオブジェクト
⇒ターゲットによって生成または取得されるオブジェクト
(3)疑似オブジェクト
⇒疑似オブジェクトのパターンに従うコラボレーターのサブクラス (または実装)
(4)特化オブジェクト
⇒コラボレーターの代わりに疑似を返すよう生成メソッドをオーバーライドする、ターゲットのサブクラス
■理解した(であろう)内容
ネット上に存在するサンプルは、ターゲットとコラボレーターが同一レイヤーに存在すう事が前提になっているようだ。(ターゲットがコラボレーターをコンストラクタもしくはメソッドの引数で取得するようなクラス設計になっている)
コラボレーターとターゲットが同一レイヤーに存在する場合はそれでも問題ないが、
・ターゲットオブジェクト ⇒ 業務処理ロジック層
・コラボレーターオブジェクト ⇒ データベースアクセス層
といったケースの場合、ターゲットを利用するレイヤーはコラボレーターの存在を知らない事という設計である為、ネット上のサンプルを適用する事は難しい。
よって、ターゲットはコラボレーターの生成を必ずオーバーライド可能なファクトリーメソッドで実装し、
ターゲットを継承した特化オブジェクトにてファクトリーメソッドをオーバーライドし擬似オブジェクトを返却するようにクラス設計する事!
以上のモデルをオブジェクト図で表現してみた。
■言葉の定義
Mockを使うにあたっては以下の役割を持つオブジェクトが存在する
(1)ターゲットオブジェクト
⇒テスト対象オブジェクト
(2)コラボレーターオブジェクト
⇒ターゲットによって生成または取得されるオブジェクト
(3)疑似オブジェクト
⇒疑似オブジェクトのパターンに従うコラボレーターのサブクラス (または実装)
(4)特化オブジェクト
⇒コラボレーターの代わりに疑似を返すよう生成メソッドをオーバーライドする、ターゲットのサブクラス
■理解した(であろう)内容
ネット上に存在するサンプルは、ターゲットとコラボレーターが同一レイヤーに存在すう事が前提になっているようだ。(ターゲットがコラボレーターをコンストラクタもしくはメソッドの引数で取得するようなクラス設計になっている)
コラボレーターとターゲットが同一レイヤーに存在する場合はそれでも問題ないが、
・ターゲットオブジェクト ⇒ 業務処理ロジック層
・コラボレーターオブジェクト ⇒ データベースアクセス層
といったケースの場合、ターゲットを利用するレイヤーはコラボレーターの存在を知らない事という設計である為、ネット上のサンプルを適用する事は難しい。
よって、ターゲットはコラボレーターの生成を必ずオーバーライド可能なファクトリーメソッドで実装し、
ターゲットを継承した特化オブジェクトにてファクトリーメソッドをオーバーライドし擬似オブジェクトを返却するようにクラス設計する事!
以上のモデルをオブジェクト図で表現してみた。
Mock
只今より勉強開始。
想像していたものと全然違うような気がする。
このサイトよさそうなので読書中。
■疑似オブジェクトによる単体テスト
http://www-06.ibm.com/jp/developerworks/java/030207/j_j-mocktest.html
想像していたものと全然違うような気がする。
このサイトよさそうなので読書中。
■疑似オブジェクトによる単体テスト
http://www-06.ibm.com/jp/developerworks/java/030207/j_j-mocktest.html
S2Unit.NET 体験編
いろいろ試行錯誤の結果、なんとか動作させる事ができた。
RDBMSを使用したアプリケーションのテストにはもってこいなように思える。
特に『データベースに対するテスト』でExcelを利用できるのが何よりよい。
NDbUnitだとテストデータ作成がかなり不便。
それとDIコンテナを使用しないアプリケーションに対してもテスト可能。
MbUnitについてはもう少し勉強が必要だな。NUnitを拡張してる事以外よくわかってない。
あとはCI。NAntがMbUnitに対応してくれればCI可能なんだが・・どーなんだろ。
(この場合、CIサーバーも対応してないとレポーティングが弱いか・・・)
試行錯誤した点はやはりS2TestCase#Includeが動作しなかった点。
マニュアル通りやってみたけどNullReferenceExceptionが発生する。
ソースを追っかけるとDIコンテナが作られてないようだ。
今の所特にS2TestCase#Includeを利用する必要性もないので実装せず、
アプリケーション構成ファイルに定義したdiconファイルを利用するようにした。
後はマニュアル通りにやると動いた。
RDBMSを使用したアプリケーションのテストにはもってこいなように思える。
特に『データベースに対するテスト』でExcelを利用できるのが何よりよい。
NDbUnitだとテストデータ作成がかなり不便。
それとDIコンテナを使用しないアプリケーションに対してもテスト可能。
MbUnitについてはもう少し勉強が必要だな。NUnitを拡張してる事以外よくわかってない。
あとはCI。NAntがMbUnitに対応してくれればCI可能なんだが・・どーなんだろ。
(この場合、CIサーバーも対応してないとレポーティングが弱いか・・・)
試行錯誤した点はやはりS2TestCase#Includeが動作しなかった点。
マニュアル通りやってみたけどNullReferenceExceptionが発生する。
ソースを追っかけるとDIコンテナが作られてないようだ。
今の所特にS2TestCase#Includeを利用する必要性もないので実装せず、
アプリケーション構成ファイルに定義したdiconファイルを利用するようにした。
後はマニュアル通りにやると動いた。
SciretとTaskJuggler
MOONGIFTに紹介されたオープンソースプロダクト。
是非評価してみたいのでメモ。(共に日本語化が大丈夫かが気になる・・・)
特にSciretは使えそうなんだけど。
■Sciret
http://sciret.sourceforge.net/
ナレッジマネージメントシステム。
特徴としてはユーザーインターフェースがとても優れている。見やすい。
これは評価するに値するはず!
■TaskJuggler
http://www.taskjuggler.org/
テキストベースのプロジェクト管理システム。
簡単なマークアップ言語の習得が必要そうだけど、
ガントチャートや様々なレポーティング機能を保持している。
ちょっと導入に苦労しそうだけど、なかなかよさそう。
是非評価してみたいのでメモ。(共に日本語化が大丈夫かが気になる・・・)
特にSciretは使えそうなんだけど。
■Sciret
http://sciret.sourceforge.net/
ナレッジマネージメントシステム。
特徴としてはユーザーインターフェースがとても優れている。見やすい。
これは評価するに値するはず!
■TaskJuggler
http://www.taskjuggler.org/
テキストベースのプロジェクト管理システム。
簡単なマークアップ言語の習得が必要そうだけど、
ガントチャートや様々なレポーティング機能を保持している。
ちょっと導入に苦労しそうだけど、なかなかよさそう。
2007/02/02
NAntContribのvssdiffタスク
使ってみたけど、どーもうまく動いてくれない。
というのも1行だけ出力されたoutputfile(xml)が出力されるだけだ。
ネットでいろいろ調べてみたが情報量が少なくわかんない。
という事でNAntContribのソースを見てみる事にした。
DiffTaskクラスのItemDiffメソッドでDiffってるぽいのでIVSSVersionクラスのActionプロパティにログを仕込んでみた。
なるほど。チェンジアクション(Created,Checkin等)の判定を文字列比較で行っているのだが、おもいっきりEnglishで比較している為、日本語VSS環境では1件もリビジョンが拾えてない。
具体的には以下のアクション文字列を判定しレポートするかしないかを判断している。
・Labeled ⇒ ラベル設定
・Add ⇒ 追加(?)
・Create ⇒ 作成
・Check ⇒ チェックイン
なので上記文字列を対応する日本語に代えてNAntContribをビルド。
NAntから動作させるとうまくレポートしてくれた。
ひょっとして別の方法があるかもーと思いつつ、今回はこれで対応!
<結論>
日本語環境のVSSでNAntContribのvssdiffタスクは正常にレポートしてくれない。
原因はリビジョンアクションの判定を英語で行っている為。
<対応>
1.NAntContribのSolutionを立ち上げるとNAntへの参照パスが不正なので変更。
(これはしなくてもbuildファイルにてちゃんと定義してるようなのでいらないかも)
2.NAntContribのDiffTask#ItemDiff()を修正し付属のbuildファイルを利用しNAntでビルド。(※VisualStudioでビルドするとエラーになる)
3.buildディレクトリにアセンブリが作成されるのでそれをNAntのbinにコピー。
4.再びvssdiffを起動すると正常にレポートされる。
念のため、ソース修正したところを添付。
(DiffTask#ItemDiff()の120行目あたりから数行)
// We found our version so stop adding versions to our list
//if (action.StartsWith ("Labeled '" + _label + "'")) {
if (action.StartsWith ("ラベル設定 '" + _label + "'")) { labeledVersion = version.VersionNumber;
addVersion = false;
//This is a bit annoying, it would be more efficient to break
//out of the loop here but VSS throws an exception !%?!
//http://tinyurl.com/nmct
//break;
}
if (addVersion == true) {
// Only add versions that have been added,created or checked in. Ignore label actions.
//if( (action.StartsWith("Add")) || (action.StartsWith("Create")) || (action.StartsWith("Check") ))
if( (action.StartsWith("追加")) || (action.StartsWith("作成")) || (action.StartsWith("チェック") ))
{
・
・
・
というのも1行だけ出力されたoutputfile(xml)が出力されるだけだ。
ネットでいろいろ調べてみたが情報量が少なくわかんない。
という事でNAntContribのソースを見てみる事にした。
DiffTaskクラスのItemDiffメソッドでDiffってるぽいのでIVSSVersionクラスのActionプロパティにログを仕込んでみた。
なるほど。チェンジアクション(Created,Checkin等)の判定を文字列比較で行っているのだが、おもいっきりEnglishで比較している為、日本語VSS環境では1件もリビジョンが拾えてない。
具体的には以下のアクション文字列を判定しレポートするかしないかを判断している。
・Labeled ⇒ ラベル設定
・Add ⇒ 追加(?)
・Create ⇒ 作成
・Check ⇒ チェックイン
なので上記文字列を対応する日本語に代えてNAntContribをビルド。
NAntから動作させるとうまくレポートしてくれた。
ひょっとして別の方法があるかもーと思いつつ、今回はこれで対応!
<結論>
日本語環境のVSSでNAntContribのvssdiffタスクは正常にレポートしてくれない。
原因はリビジョンアクションの判定を英語で行っている為。
<対応>
1.NAntContribのSolutionを立ち上げるとNAntへの参照パスが不正なので変更。
(これはしなくてもbuildファイルにてちゃんと定義してるようなのでいらないかも)
2.NAntContribのDiffTask#ItemDiff()を修正し付属のbuildファイルを利用しNAntでビルド。(※VisualStudioでビルドするとエラーになる)
3.buildディレクトリにアセンブリが作成されるのでそれをNAntのbinにコピー。
4.再びvssdiffを起動すると正常にレポートされる。
念のため、ソース修正したところを添付。
(DiffTask#ItemDiff()の120行目あたりから数行)
// We found our version so stop adding versions to our list
//if (action.StartsWith ("Labeled '" + _label + "'")) {
if (action.StartsWith ("ラベル設定 '" + _label + "'")) { labeledVersion = version.VersionNumber;
addVersion = false;
//This is a bit annoying, it would be more efficient to break
//out of the loop here but VSS throws an exception !%?!
//http://tinyurl.com/nmct
//break;
}
if (addVersion == true) {
// Only add versions that have been added,created or checked in. Ignore label actions.
//if( (action.StartsWith("Add")) || (action.StartsWith("Create")) || (action.StartsWith("Check") ))
if( (action.StartsWith("追加")) || (action.StartsWith("作成")) || (action.StartsWith("チェック") ))
{
・
・
・
登録:
コメント (Atom)