La comprobación del file .csproj en TFS mediante enlaces .NET arroja un error no fatal de ItemNotFound

/* Make some changes to .csproj file */ ... Workspace workspace = GetWorkspace( localBranchPath, serverBranchPath ); workspace.PendEdit( csprojFilePath ); 

En este punto, mi controller de errores no fatal para VersionControlServer detecta un error de ItemNotFound. Sin embargo, si ejecuto workspace.PendEdit( csprojFilePath + ".balls" ) en la window workspace.PendEdit( csprojFilePath + ".balls" ) depurador de Visual Studio, no se producen errores y el file se comtesting correctamente.

Confirmé que el file no está marcado como de solo lectura y que el usuario que ejecuta IIS / la implementación de la aplicación y el usuario que se suplantó tienen permissions de control total de NTFS y TFS para el file .csproj.

TFS y su concepto de "espacios de trabajo" es probablemente la causa de sus problemas. Cosas raras pueden suceder si tiene más de 1 espacio de trabajo en la máquina. ¿Puede registrar qué área de trabajo se adquiere cuando ejecuta su aplicación en IIS? Es probable que no sea lo mismo (o ninguno) como el que Visual Studio crea automáticamente para usted y que obtiene / usa cuando lo ejecuta desde VS.

EDITAR : Acabo de recordar algo de mi trabajo cuando era un 'ingeniero de compilation': TFS crea espacios de trabajo por usuario y los almacena en caching para un acceso rápido en un file xml en una carpeta como C: \ Users [usuario específico] \ AppData \ Local \ Microsoft \ Team Foundation …. Verifica ese file xml. Así que estoy bastante seguro de que su usuario bajo el cual se ejecuta su grupo de aplicaciones IIS no puede ver su workpsace de usuario normal bajo la cual VS se está ejecutando. Intente configurar su propio usuario como el usuario del grupo de aplicaciones IIS y vea qué sucede. Bastante seguro funcionará como en Visual Studio. De modo que el (los) espacio (s) de trabajo de mapeo (es) para * usuario es muy concreto: puede que necesite crear un nuevo espacio de trabajo para su count de IIS y tal vez también download los files.


Otras posibilidades: un problema de permiso o la máquina IIS no puede ver la carpeta (¿de networking?) Que necesita ver.

Inicie su Visual Studio como el usuario bajo el cual se ejecuta su grupo de aplicaciones en IIS (en Windows 7, mantenga presionada la tecla shift y haga clic para ver la opción para ejecutar como usuario diferente) y vea si puede get la misma exception. Si lo haces, es un problema de permiso.

Si no obtiene el mismo error, diríjase al server IIS desde la location de alojamiento desde la que se ejecuta su aplicación y trate de acceder a la ruta como si su aplicación la accediera.

Resulta que había dos cosas mal con mi código (como era de esperar, la extensión .csproj no tuvo nada que ver con esto):

  1. Había estado revisando un file diferente antes del .csproj; a pesar de que originalmente había establecido recursivamente el control total sin lectura +, esto estaba restableciendo automáticamente el atributo de solo lectura en todo, lo que evidentemente ocasionó problemas con mis bashs posteriores de salida.

  2. En algunos casos, ya sea por conflictos u otras razones, tuve que hacer un esfuerzo para get la última versión (GetOptions.Overwrite) antes de modificar y verificar el file .csproj.