Visual Studio の一部の機能には、次のプライマリ相互運用機能アセンブリ (PIA) が必要です。
1Microsoft Visual Studio Tools for the Microsoft Office System プロジェクトを作成するために必要です。 Office プロジェクトを作成するとき、必要な PIA がインストールされていない場合、Visual Studio によってインストールが試みられます。 Office のインストール時に PIA を [初めて実行するときにインストール] に設定していなかった場合、これらをインストールするために Office のインストール メディアと管理権限が必要になることがあります。 Excel、Word、および Outlook のプロジェクトを作成するか、手動で PIA をインストールしてください。
2Microsoft Office と Visual Studio 2005 Team Foundation Server (チーム エクスプローラを含む) の統合のために必要です。
必要なプライマリ相互運用機能アセンブリ (PIA) を手動でインストールするには
Office 2003 のフル バージョンを使用している場合は、次の手順に従って PIA を手動でインストールできます。Excel、Outlook、および Word 単独のバージョンの場合も同様の手順を使用できますが、使用できない PIA もあります。
メモ Service Pack を使用して Windows Server 2003 をアップグレードするだけであれば、この問題は発生しません。 これは、Windows Server 2003 と Windows Server 2003 SP1 の両方が含まれている CD でアップグレードを行った場合に発生する問題です。
Team Foundation Server の再インストールまたはアップグレードを行う際にサービス アカウントを変更した場合、既存のサービス アカウントに対するアクセス許可は削除されないので、セキュリティ上の問題が生じる可能性があります。
この問題を解決するには
サービス アカウントを変更する必要がある場合は、元のサービス アカウントで再インストールを行ってから、TfsAdminUtil.exe コマンドライン ユーティリティの ChangeAccount コマンドを使用してサービス アカウントを変更してください。
インストールできる Visual Studio 2008 Beta 2 チーム エクスプローラの言語バージョンは 1 つだけです。
この問題を解決するには
この問題の回避策はありません。
Windows Server 2003 SP1 の完全インストールが収録された CD を使用してアップグレードすると、コンピュータ上にある mscoree.dll 共有ファイルが .NET Framework 1.1 mscoree.dll ファイルで置き換えられます。 .NET Framework 2.0 向けにコンパイルされたアプリケーションは、この Service Pack をインストールすると動作しなくなります。
この問題を解決するには
Service Pack をインストールした後で、.NET Framework を修復する必要があります。
メモ Service Pack を使用して Windows Server 2003 をアップグレードするだけであれば、この問題は発生しません。 これは、Windows Server 2003 と Windows Server 2003 SP1 の両方が含まれている CD でアップグレードを行った場合に発生する問題です。
この問題を解決するには
Team Foundation ビルドをインストールする前に .NET Framework 3.5 をインストールしてください。 .NET Framework 3.5 は、Team Foundation インストール メディアの ..\wcu\dotNetFramework フォルダにある dotNetFx35Setup.exe ファイルを使用してインストールできます。
既知の問題はありません。
既定では、IIS_WPG ユーザー (Windows Server 2003) および IIS_IUSRS ユーザー (Windows Server 2008) には、...\Web Services\VersionControlProxy\app_data フォルダに対する書き込みのアクセス許可が与えられていません。 この問題では、このフォルダへのアクセスが拒否されたことを示す項目がイベント ログに書き込まれます。 実際には、このフォルダは存在しません。 そのため、イベント ログにエラーが書き込まれるだけでなく、ProxyStatistics.xml ファイルがこのフォルダに保存されません。
この問題を解決するには
この問題を解決するには、手動で新しい app_data フォルダを作成し、適切なアクセス許可を適用する必要があります。
Analysis Services は、Microsoft Visual Studio 2008 Team Foundation Server の非データ層コンピュータに移動できます。 ただし、Team Foundation Server データ層が SQL Server データベース クラスタ内にセットアップされている場合は、Analysis Services を移動できません。
この問題を解決するには
クラスタ化されたサーバー環境での回避策はありません。
Team Foundation Server のデータ層コンピュータに Analysis Services がある環境では、Analysis Services データベースを別のサーバーに移動できます。 詳細については、http://msdn2.microsoft.com/ja-jp/library/aa721760(vs.90).aspx を参照してください。
TFSAdminUtil changeaccount を実行してサービス アカウントを変更すると、Visual Studio Team Foundation Server Task Scheduler が機能しなくなります。
Visual Studio 2008 Beta 2 Team Foundation Server では、TFSAdminUtil changeaccount コマンドを実行しても、ファイル システムに対するアクセス制御リスト (ACL) は変更されません。 このため、Changeaccount コマンドを使用して作成した新しいサービス アカウントには、%windows%\temp フォルダへの必要なアクセス許可がありません。 Visual Studio Team Foundation Server Task Scheduler を起動するには、このフォルダへのアクセス許可が必要です。
この問題を解決するには
新しいサービス アカウントに、%windows%\temp フォルダに対する [読み取りと実行]、[フォルダの内容の一覧表示]、[読み取り]、および [書き込み] のアクセス許可を与える必要があります。
Visual SourceSafe 内のファイルまたはフォルダについて、名前空間の変更履歴があると、VSSConverter がデータを正しく移行できない場合があります。 名前変更、アーカイブと復元、共有、分岐、移動などの編集イベントによって、Visual SourceSafe の履歴内で名前空間の競合が生じることがあります。 このような競合は、ファイルおよびフォルダが正しく移行されない結果につながります。 変換されたファイルにバージョンの欠落がある場合や、変換によってファイルがなくなった場合には、この問題が生じていると見なすことができます。 ログ ファイルまたは移行レポートに、"The item already exists." および "The item could not be found in the workspace." というエラーが記録されます。 このバグは、Visual Studio 2005 Team System と Visual Studio 2008 Beta 2 Team System の両方に存在します。
この問題を解決するには
設定ファイル内でマッピングを変更するとファイルを正しく移行できるようになる場合があります。 欠落しているバージョンが、たとえば ProjA というフォルダ内にあることがわかっている場合は、マッピングを ProjA のサブフォルダに変更できます。 たとえば、次のようなマッピングがあるとします。
<ProjectMap>
<Project Source="$/Projects/ProjA" Destination="$/TFSProjects/ProjA" />
</ProjectMap>
これを次のように変更できます。
<ProjectMap>
<Project Source="$/Projects/ProjA/SubFolder1" Destination="$/TFSProjects/ProjA/SubFolder1" />
<Project Source="$/Projects/ProjA/SubFolder2" Destination="$/TFSProjects/ProjA/SubFolder2" />
<Project Source="$/Projects/ProjA/SubFolder3" Destination="$/TFSProjects/ProjA/SubFolder3" />
</ProjectMap>
設定ファイル内でマッピングを変更したら、VSSConverter を再度実行します。これで正しく移行されていないファイルがあれば、データは VSSConverter で移行されません。
作業項目の種類で [担当者] フィールドの <ALLOWEDVALUES> リストに新しいユーザーを追加したにもかかわらず、そのユーザーが既存の Excel リストに表示されない場合があります。 これは、Excel のキャッシュでユーザー リストが更新されていないために発生します。
この問題を解決するには
Excel ブックを終了してからファイルを開き直し、[更新] をクリックしてユーザー リストを更新します。
- または -
新しいリスト オブジェクトをファイルに追加します。 詳細については、「方法 : Microsoft Excel や Microsoft Project から Team Foundation に接続する」の「作業項目リストを Team Foundation に接続させるには」を参照してください。
Visual Studio 2008 Beta 2 Team Foundation Server の日本語版では、MSF for Agile Software Development プロセス テンプレートまたは MSF for CMMI Process Improvement プロセス テンプレートを使用して Visual Studio 2005 Team System クライアントでチーム プロジェクトを作成した場合、プロジェクトの作成が失敗します。
新しいチーム プロジェクト ウィザードにより、次のエラー メッセージが表示されます。
TF30169: 新しいチーム プロジェクト ウィザードでは、プロセス テンプレート {0} をダウンロードできませんでした。
この問題を解決するには
Microsoft Visual Studio 2005 Team System クライアントで読み取ることができるようにプロセス テンプレート ファイルを圧縮するには、次の手順を実行します。
これで、両方のテンプレートに対して Visual Studio 2005 Team Foundation Server の新しいチーム プロジェクト ウィザードを使用できるようになりました。
品質指標レポートおよび再アクティブ化レポートは、プロセス ガイダンスの最終リリース用更新の後に更新されました。 そのため、プロセス ガイダンスの画像がレポートと一致しません。
この問題を解決するには
現時点での回避策はありません。
メモ帳で XML、.HTM、.WIQ、.RDL の各ファイルを編集し、Ctrl キーを押しながら S キーを押して保存する場合、使用される既定のエンコーディングは ANSI です。 ファイルに ASCII 以外の文字が含まれている場合は、これにより問題が発生します。
この問題を解決するには
プロセス テンプレートで .XML、.HTM、.WIQ、.RDL のいずれかのファイルを編集した場合は、"UTF-8 シグネチャ (BOM) 付き" エンコーディング (Visual Studio で編集する場合) または "UTF-8" (メモ帳を使用する場合) で保存します。 その他のエディタの場合は、ファイルの先頭に BOM (Byte Order Mark) を付加し、UTF-8 エンコーディングで保存してください。 BOM の存在は、ファイルの先頭 3 バイトをチェックすることによって検出できます。 EF BB BF (16 進) が BOM です。
一部のオペレーティング システムでは、特定の Unicode 文字を含んだ URL を Windows SharePoint Services で正しく読み込むことができません。 このことが原因で、チーム ポータルとプロセス ガイダンスが部分的にしか表示されない場合があります。
この問題を解決するには
Internet Explorer で URL が UTF-8 文字列として送信されるようにするには、次の手順を実行します。
単一サーバー、ワークグループ配置の Team Foundation Server のレポート Web サイトにアクセスすると、最初のアクセス時に資格情報の入力を求められます。 それ以降のアクセスでは、資格情報の入力が求められず、レポートを表示できません。
この問題を解決するには
ローカル イントラネット ゾーンでは常にユーザー名とパスワードの入力が求められるように、Internet Explorer を構成してください。
OLAP データベースとウェアハウス リレーショナル データベースとの同期が失われる場合があります。 この場合、カスタム作業項目の種類に追加されたフィールドが、作業項目の種類の定義で "reportable" と構成されていても、Team System キューブに表示されません。
この問題を解決するには
アプリケーション層で http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx?op=Run に移動し、[呼び出し] をクリックしてウェアハウス Web サービスの Run メソッドを実行します。
Internet Explorer の言語の設定が Team Foundation Server 製品の言語と異なると、X 軸の日付が表示されません。
この問題を解決するには
Internet Explorer の言語設定を変更して、Team Foundation Server に使用されている言語と一致させてください。
Internet Explorer で使用される言語を変更するには、次の手順を実行します。
Windows Vista では、アラビア語 (サウジアラビア) の既定のカレンダーが、ヒジュラ暦からウムアルクラ暦に変更されています。 この 2 つは異なるカレンダーであるため、ウムアルクラ暦の日付を使ったレポートでは不正確なデータが出力される場合があります。
この問題を解決するには
Windows Vista クライアントでは、ウムアルクラ暦をヒジュラ暦に変更してください。
アプリケーション層が Windows Server 2008 にインストールされており、サービス アカウントがドメイン アカウントではなく Network Service である場合、バージョン管理アダプタは変更セットの処理に失敗します。 この問題は、アダプタによって VersionControl_Data フォルダが作成されなかったことが原因で発生します。
この問題を解決するには
Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\Warehouse\ フォルダ内に、VersionControl_Data という名前のフォルダを作成します。 アプリケーション層を実行するサービス アカウントに、VersionControl_Data フォルダに対する [読み取り] および [書き込み] のアクセス許可を与えます。
Team Foundation Server の再構成または復元後に、チーム エクスプローラからサーバーへの接続に問題が発生する場合があります。 "TF31005: Team Foundation Server <server name> に接続できないため、Team Foundation はチーム プロジェクトのリストを取得できません。" というエラーが表示されます。 この問題は、ローカルにキャッシュされたデータが Team Foundation Server と同期されていない場合に発生します。
この問題を解決するには
チーム エクスプローラが自動的に更新される (2 時間以内) まで待つか、ローカル キャッシュを手動でクリアします。
手動でローカル キャッシュをクリアするには、次の手順を実行します。
Windows SharePoint Services の既知の制限により、中国語、日本語、および韓国語の拡張文字 A および B を含むチーム プロジェクト ポータルはサポートされません。 このため、これらの文字はチーム プロジェクト名にも使用できません。
この問題を解決するには
現時点ではこの問題の回避策はありません。
セキュリティ更新プログラム 896358 がインストールされているコンピュータでは、ダウンロードした CHM (Compiled Help Module) ファイルを開くことができません。
この問題を解決するには
KB902225 を参照してください。
Team Foundation ビルドから実行したリモート テストは、"接続済みの呼び出し先が一定の時間を過ぎても正しく応答しなかったため、接続できませんでした。または接続済みのホストが応答しなかったため、確立された接続は失敗しました。" というエラー メッセージが表示されて失敗します。
Team Foundation ビルドからリモート テストを実行する場合、ビルドの実行に使用するユーザー アカウントが、Team Test Load Agent Controller コンピュータの TeamTestControllerUser ローカル セキュリティ アカウントまたは TeamTestControllerAdmins ローカル セキュリティ アカウントのメンバである必要があります。 また、Windows ファイアウォール (またはサードパーティ製のファイアウォール ソリューション) を使用している場合、MSBuild がリモート コンピュータにアクセスできるようにする必要があります。
この問題を解決するには
Team Test Load Agent Controller コンピュータの TeamTestControllerUser ローカル セキュリティ アカウントまたは TeamTestControllerAdmins ローカル セキュリティ アカウントに、ビルドの実行に使用するユーザー アカウントを追加します。 さらに、Team Foundation ビルド コンピュータで、Windows ファイアウォール (またはサードパーティ製のファイアウォール ソリューション) の例外リストに MSBuild を追加します。
Visual Studio Team Foundation ビルド サービスの実行に使用するアカウントを変更した場合、新しいユーザー アカウントにいくつかのアクセス許可を追加する必要があります。
この問題を解決するには
Visual Studio Team Foundation ビルド サービス アカウントが次の状態になるようにしてください。
Team Foundation Server にある既存のチーム プロジェクトを削除してから、同じ名前で新しいチーム プロジェクトを作成した場合、チーム エクスプローラが元のチーム プロジェクトを参照していると、新しいビルド定義を作成できません。
この問題を解決するには
この問題が発生した場合は、そのコンピュータで Visual Studio を再起動してください。
Visual Studio Team Foundation ビルド サービス ユーザーが Network Service である構成で Team Foundation ビルドがインストールされている場合、チーム エクスプローラのプロジェクト グループを使用して "NT Authority\Network Service" ユーザーまたは "<BuildComputerName>$" ユーザーを [Team Project]\ビルド サービス グループに追加することはできません。
詳細 :
この問題を解決するには
TFSSecurity.exe コマンドライン ツールを使用して、ビルド サービス グループに Network Service ユーザーを追加します。
Team Foundation アプリケーション層と同じコンピュータでチーム ビルド サービスが実行されている場合、追加するユーザーはサーバー名ではなく Network Service ユーザーにする必要があります。
例 : TFSSecurity.exe /server:myTFS /g+ "[myTeamProject]\Build Services" "Network Service"
既知の問題はありません。
既知の問題はありません。