ログイン画面でのユーザ名非表示

今日は完全に覚書です。

ログイン画面に特定のユーザ名を表示させたくない場合、
 ・レジストリエディタで「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList」まで移動
  (インストール直後だと、「SpecialAccounts」と「UserList」を作成する必要あり)
 ・新規で「DWORD(32ビット値)」を作成し、名前を非表示にしたいユーザ名にする
 ・値は’0’が非表示、’1’が表示

ちなみに、「前回のログインユーザ名を表示させたくない」場合は、グループポリシーエディタから、
 ・「ローカルコンピュータポリシー」-「コンピューターの構成」-「Windowsの設定」-「セキュリティの設定」-「ローカルポリシー」-「セキュリティオプション」を選択
 ・「対話型ログオン:最後のユーザ名を表示しない」を有効に変更

勉強会参加:第18回 .NET 勉強会 / ヒーロー島

9/25開催の「第18回 .NET 勉強会 / ヒーロー島」に参加させて頂きました。

今回のゲストは
・「サイトコア株式会社」の原水さんによるSitecore CMS
 →原水さんのセッションは初めてだったと思います。
・の北端さんによるSharePoint2010インストール
 →ご本人曰く「Exchangeが本職」にはちょっとびっくりでした。
・ご存じ はるか さおさんによるSilverlight サンプル
 →さおさんのセッションも初めてだったと思います。
という豪勢な構成でした。

また、TechEd2010で発射されたミサイル(RemoteFX USBデバイス リダイレクト)の実演もあり
、いろんなことが聞けた一日でした。

恒例の懇親会には、セッションゲストに加えて
 ・MVPリードの笹瀬さん
 ・「Windows Server 2008 R2 構築・運用・管理パーフェクトガイド」の著者 知北さん
も合流され、とても楽しい時間を過ごせました。
(パーフェクトガイドは帰りがけにさっそく購入させていただきました)

また次回も参加させて頂ければと思います。
※今度の勉強会は3周年記念とのことです。

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

さて、Eclipse編ですが、結論は「Eclipseだとちょっと使いづらい」です。

ゲートチェックインなしの場合はVS IDEと同じ動き(自動で「保留中の変更」が調整される)になります。

ゲートチェックインありの場合、ゲートチェックイン完了まではVS IDEと同じです。
・ゲートチェックイン正常終了時

Scr000072

ここから少し動作が異なるのが、「ビルド処理ログ表示画面からワークスペースの調整が行えない」というものです。
先ほどの「ゲートチェックイン正常終了時」に「ビルド処理ログ表示画面」も表示されていますが、VS IDEでは表示されていた「ワークスペースの調整」がありません。

ビルドが完了しているのが分かっているのに、通知を待たないといけないのはちょっといやですね。

あれ?、Windowsなら完了通知あるけど、MacとかLinuxだとどうすればいいんだろう??

ゲートチェックイン時のソース管理状態 その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の環境変数サイズの名残でつい(^_^;)
のでフォルダを変更してしまうのですが、たまには変更しないほうが良い時もあると。