/* Make some changes to .csproj file */
...
Workspace workspace = GetWorkspace( localBranchPath, serverBranchPath );
workspace.PendEdit( csprojFilePath );
この時点で、VersionControlServerの致命的ではないエラーハンドラーがItemNotFoundエラーをキャッチします。ただし、workspace.PendEdit( csprojFilePath + ".balls" )Visual Studioデバッガーの[監視]ウィンドウで実行すると、エラーは発生せず、ファイルは適切にチェックアウトされます。
ファイルが読み取り専用としてマークされておらず、IIS /アプリの展開を実行しているユーザーと偽装されているユーザーの両方が、.csprojファイルに対するNTFSとTFSのフルコントロールアクセス許可を持っていることを確認しました。
TFS とその「ワークスペース」の概念が問題の原因である可能性があります。マシン上に複数のワークスペースがある場合、奇妙なことが起こる可能性があります。IIS でアプリを実行したときに取得されるワークスペースをログに記録できますか? Visual Studio が自動的に作成し、VS から実行するときに取得/使用するものと同じではない (またはまったくない!) 可能性があります。
編集:私が「ビルドエンジニア」だったときの私の仕事から何かを思い出しました:TFSはユーザーごとにワークスペースを作成し、C:\Users[sepcific user]\AppData\Local\のようなフォルダー内のxmlファイルに高速アクセスのためにそれらをキャッシュしますMicrosoft\Team Foundation ... . そのxmlファイルを確認してください。したがって、IIS アプリケーション プールが実行されているユーザーは、VS が実行されている通常のユーザー ワークスペースを確認できないと確信しています。独自のユーザーを IIS アプリ プール ユーザーとして設定してみて、何が起こるかを確認してください。Visual Studio のように動作することは間違いありません。そのため、*userへのワークスペースのマッピングは非常に具体的です。IIS アカウント用に新しいワークスペースを作成し、ファイルもダウンロードする必要がある場合があります。
その他の可能性: アクセス許可の問題、または IIS マシンが必要な (ネットワーク?) フォルダーを認識できない。
IIS でアプリケーション プールを実行しているユーザーとして Visual Studio を起動し (Windows 7 ではshift、別のユーザーとして実行するオプションを表示するには、長押しして右クリックします)、同じ例外が発生するかどうかを確認します。もしそうなら、それは許可の問題です。
同じエラーが発生しない場合は、アプリケーションが実行されているホストの場所から IIS サーバーに移動し、アプリがアクセスするかのようにパスにアクセスしてみてください。
私のコードには 2 つの問題があったことが判明しました (予想通り、.csproj 拡張子はそれとは関係ありません)。
.csproj の前に別のファイルをチェックインしていました。もともと非読み取り専用 + フル コントロールを再帰的に設定していたにもかかわらず、これによりすべての読み取り専用属性が自動的に再設定され、その後のチェックアウト試行で明らかに問題が発生しました。
場合によっては、競合やその他の理由により、.csproj ファイルを変更してチェックアウトする前に、強制的に最新のものを取得する (GetOptions.Overwrite) 必要がありました。