TFS 2012 Build "Acceso a ruta denegada"

access-denied

Question

Estoy usando TFS 2012 Build y me encuentro con un error

Se niega el acceso a la ruta

La solución que se está creando contiene aproximadamente 15 proyectos, de los cuales un número usa el ensamblado Castle.Components.Validator.2.5.0.

He visto otras publicaciones que hablan de los errores de acceso de compilación de TFS, pero generalmente se refieren a la ejecución simultánea de compilaciones. En este caso, solo se ejecuta una compilación a la vez. Además, el error ocurre cuando se reinicia el servidor o la compilación no se ha ejecutado durante un tiempo.

Una vez que se ejecuta una compilación y falla, la siguiente tiene éxito y cada una de ellas vuelve a tener éxito hasta que la compilación no se haya ejecutado durante un tiempo o el servidor se haya reiniciado. Aunque podemos evitar esto, es un dolor de cabeza manual.

Aquí está el error:

C: / WINDOWS / Microsoft.NET / Framework64 / v4.0.30319 / Microsoft.Common.targets (3513): no se puede copiar el archivo "D: / Builds / 12 / Foo / Check-In Build / Sources / packages / Castle.Components .Validator.2.5.0 / lib / NET40 / Castle.Components.Validator.dll "a" D: / Builds / 12 / Foo / Check-In Build / Binaries / Castle.Components.Validator.dll ".

Se deniega el acceso a la ruta ''D: / Builds / 12 / Foo / Check-In Build / Binaries / Castle.Components.Validator.dll''.

Al mirar el archivo de registro, puede ver que la compilación está intentando copiar el archivo dos veces. Como el primero tiene un bloqueo en el archivo, el segundo falla y, por lo tanto, falla la compilación. Aquí hay un fragmento del archivo de registro que muestra lo que está sucediendo:

2> _CopyFilesMarkedCopyLocal: copiando archivo de "D: / Builds / 12 / Foo / Check-In Build / Sources / packages / Castle.Components.Validator.2.5.0 / lib / NET40 / Castle.Components.Validator.dll" to " D: / Builds / 12 / Foo / Check-In Build / Binaries / Castle.Components.Validator.dll ".

5> _CopyFilesMarkedCopyLocal: Copiando archivo desde "D: / Builds / 12 / Foo / Check-In Build / Sources / packages / Castle.Components.Validator.2.5.0 / lib / NET40 / Castle.Components.Validator.dll" a " D: / Builds / 12 / Foo / Check-In Build / Binaries / Castle.Components.Validator.dll ".

2> _CopyFilesMarkedCopyLocal: copiando archivo de "D: / Builds / 12 / Foo / Check-In Build / Sources / packages / MvcContrib.Mvc3.FluentHtml-ci.3.0.96.0 / lib / MvcContrib.FluentHtml.dll" a "D: / Builds / 12 / Foo / Check-In Build / Binaries / MvcContrib.FluentHtml.dll ". Copiando archivos de "D: / Builds / 12 / Foo / Check-In Build / Sources / packages / RhinoMocks.3.6 / lib / Rhino.Mocks.dll" a "D: / Builds / 12 / Foo / Check-In Build / Binarios / Rhino.Mocks.dll ".

Cualquier ayuda sobre cómo solucionar esto sería muy apreciada.

Answer 1

Parece que hay dos proyectos copiando el mismo archivo. Dependiendo del momento, a veces ocurren al mismo tiempo, lo que resulta en la falla. Debe volver a rastrear el id del nodo para encontrar el proyecto fuente. Consulte http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx para obtener más detalles y códigos que pueden rastrear hacia abajo para ti.

Answer 2

Como Buck Hodges y Nimblejoe han dicho con razón, esto se debe principalmente a que TFS ejecuta múltiples procesos de MSBuild de forma predeterminada para construir sus proyectos.

Puede anularlo en la definición de compilación en Proceso -> 3. Avanzado -> Argumentos de MSBuild agregando el argumento MSBuild / p: BuildInParallel = false

Answer 3

Esto también puede suceder si tiene abierta la carpeta de un agente de compilación.

Answer 4

como muchas personas ya lo han expresado anteriormente, esto sucede cuando se construyen proyectos en paralelo. Los proyectos A y B que hacen referencia a la Biblioteca C de terceros (Copiar local) causarán esto cuando se compilen al mismo tiempo, uno al lado del otro.

El verdadero problema es que TFS Build 2012 y siguientes están configurados para que al crear una solución, toda la salida de la solución se copie en una única carpeta. Ahí es donde los dolores de las construcciones paralelas tienen sus orígenes.

Desde TFS 2013, puede resolverlo fácilmente estableciendo la "Ubicación de salida" en la definición de construcción en "PerProject". Esto obliga a los servicios de compilación a comportarse como una ejecución de msbuild local donde las lecturas relativas a las ubicaciones de salida se leen desde los archivos de proyecto correspondientes. Por lo tanto, la salida se escribe en las carpetas bin debajo de cada proyecto.

Para TFS 2012 y siguientes, este artículo (+ artículos vinculados) lo ayudará a obtener el mismo resultado que con TFS 2013:

http://blog.stangroome.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/

Answer 5

Resolví un problema similar al cerrar todas las instancias abiertas de Visual Studio, volver a abrir la solución y compilarla de nuevo.

Answer 6

También tuve el mismo problema. Recibí mensajes de error que no se pueden copiar porque el acceso a la ruta fue denegado. En mi caso, todos mis archivos dll y xml, etc., se ubican en la carpeta D: / TFS / Example / Bin / Debug.

Hice clic derecho en la carpeta Bin e hice clic en Propiedades y vi que la casilla de verificación de solo lectura está marcada en Atributos.

Desactivé la casilla de verificación Solo lectura y presioné Aplicar y hice clic en Aceptar en la nueva ventana emergente que se muestra.

Volví a Visual Studio y construí mi solución que me daba mensajes de error.

Voilaa .. Esta vez se construye con éxito sin errores.

No sé si esto es perfecto, pero lo hice para resolver mi problema.

Answer 7

Al igual que Ziggler, resolví este problema al crear un proyecto al eliminar la propiedad ''solo lectura'' de la carpeta bin de mi proyecto. Solo sucede con los archivos XML almacenados en un directorio / packages / que es común a la solución que contiene este proyecto. La carpeta ''bin'' no está marcada en el control de fuente. Todavía estoy perplejo en cuanto a la causa raíz del problema.

Answer 8

Encontré el mismo problema que ocurrió después de que la compilación intentó sobrescribir los archivos en el "Directorio de trabajo" que había creado en un intento anterior de compilación. (establecido en el agente)

Resolví esto al eliminar manualmente la carpeta de salida que creó (en mi caso [Directorio de trabajo] / Binarios) antes de intentar la compilación.

Esto se puede hacer automáticamente cambiando la definición de compilación. En Proceso --- 2.Básico --- Limpie el espacio de trabajo, establezca esto en la opción Salidas

Answer 9

Una posible causa es si tiene las carpetas bin u obj para bibliotecas de clase registradas en TFS. Al eliminar las carpetas bin u obj de los proyectos de TFS, se resolverá este problema si ese es el caso.

Answer 10

Como otros mencionaron, esto sucede cuando se realizan compilaciones multiproceso con un directorio de destino común y la tarea de copia de archivos encuentra un conflicto simultáneo con una tarea de copia que se ejecuta para un proyecto diferente.

Normalmente, esto debería dar como resultado una excepción de "archivo utilizado por otro proceso" (que se maneja y reintenta mediante la tarea de copia de archivo), pero a veces la operación de archivo da como resultado una excepción "Acceso denegado". (Todavía no estoy seguro de por qué)

Algunos sugieren que debe "resolver la duplicación", pero no veo que sea factible para los casos en que todos los proyectos necesitan hacer referencia directa a una biblioteca como log4net.

Obviamente, una forma de evitar el problema es ejecutar explícitamente msbuild con /p:BuildInParallel=false o /m:1 o /maxcpucount:1 (u omita el argumento por completo) para forzar el modo de subproceso único.

Sin embargo, en TFS 2013 , la plantilla de compilación predeterminada siempre transfiere /m (utiliza todos los núcleos) a msbuild, que reemplaza silenciosamente cualquier configuración de subproceso único que pueda pasar manualmente. (Determinado por mi propia experimentación y examen de registros de diagnóstico)

Otra solución que intenté fue pasar manualmente /p:AllowedReferenceRelatedFileExtensions=none a msbuild, lo que impide que se copien todos los archivos pdb y xml de las bibliotecas a las que se hace referencia. (Desde hace un tiempo, solo vi archivos xml con este problema). Pero seguí teniendo problemas con log4net.dll.

La última solución que utilicé fue una que descubrí descompilando el código fuente de Microsoft.Build.Tasks.Copy :

if (hrForException == -2147024891)
{
    if (!Copy.alwaysRetryCopy)
        throw;
    else
        this.LogDiagnostic("Retrying on ERROR_ACCESS_DENIED because MSBUILDALWAYSRETRY = 1", new object[0]);
}

Si se produce el error -2147024891 (se deniega el acceso 0x80070005), la tarea Copiar comprobará una variable especial para ver si debe volver a intentarlo. Ese valor se establece a través de una variable de entorno:

Copy.alwaysRetryCopy = Environment.GetEnvironmentVariable("MSBUILDALWAYSRETRY") != null;

Después de establecer la variable de entorno MSBUILDALWAYSRETRY = 1 (y reiniciar el servidor de compilación), el problema desapareció. Y también periódicamente comencé a ver "Reintentar en ERROR_ACCESS_DENIED ..." como advertencias en los registros de compilación, lo que demuestra que la configuración estaba surtiendo efecto (en lugar de que las compilaciones simplemente tengan éxito por coincidencia).

(Tenga en cuenta que esta variable de entorno no está bien documentada, utilícela según corresponda).

Actualización: Aparentemente, TFS 2015 ya no anula tu /m:1 con /m (incluso en las definiciones de compilación heredadas / XAML), lo que debería hacer que /m:1 una corrección válida nuevamente.

Answer 11

Aquí hay una variación de este problema que tuve que tratar:

No pude entender por qué mi compilación siguió fallando en un error de "Acceso a la ruta denegada", aunque agregué elementos como /p:BuildInParallel=false y /p:OverwriteReadOnlyFiles=true a los argumentos de MSBuild de mi XAML construir. La causa resultó ser una " línea de comando de evento posterior a la construcción " en las propiedades de mi proyecto.

Después de cambiar

%WinDir%/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe[SNIP] 
/P:Configuration=$(ConfigurationName);[SNIP] 
;AutoParameterizationWebConfigConnectionStrings=false

a

%WinDir%/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe[SNIP] 
/P:Configuration=$(ConfigurationName);[SNIP]
;AutoParameterizationWebConfigConnectionStrings=false;OverwriteReadOnlyFiles=true

el error desapareció

Answer 12

Estaba teniendo este problema y decidí ignorarlo porque no quería sacrificar el rendimiento de la construcción por el deseo de deshacerme de algunos mensajes de error benignos de NuGet. Sin embargo, parece que me encontré con una solución mientras trataba de resolver otro problema, y ​​creo que está relacionado. Creo que el orden de obtención de paquetes NuGet está relacionado con el orden de construcción de los proyectos en la solución. Entonces, si esto de alguna manera se ha desarticulado, entonces NuGet puede ser la primera víctima antes de que te topes con errores de compilación donde comienzas a obtener el "archivo de metadatos XXX.dll" no se pudo encontrar "errores que molestamente requieren volver a compilar hasta que la construcción tenga éxito (como se describe aquí ).

Entonces, creo que la solución es seguir los pasos descritos en la respuesta aceptada a la pregunta antes mencionada. O bien, siga los pasos más completos en una de las respuestas alternativas . En otras palabras, deshabilite la construcción de todos los proyectos, reinicie VS, luego vuelva a habilitar la construcción de todos los proyectos. Esto resolverá (normalmente) el orden de compilación. Y eso debería resolver el problema de NuGet. Por favor, avíseme si esto lo soluciona para cualquiera.

Answer 13

Tuve este problema, con TFS 2015. Resultó ser porque el agente de compilación se ejecutaba con las credenciales predeterminadas (SERVICIO DE RED), que no tenían permisos de escritura en la carpeta de destino. Una vez que eliminé el Agente y lo reinstalé con las credenciales, funcionó. Me hizo navegar por los registros durante un tiempo, comprobando y desmarcando el cuadro de múltiples procesos e incluso reiniciando el servidor de compilación en mi búsqueda. Verifique las cosas obvias primero ...