No se puede copiar el archivo: se deniega el acceso a la ruta

Estoy usando Visual Studio 2005. Después de tomar el código del control de versiones primero, la aplicación c # .net se ejecuta correctamente. Pero, después de hacer algunas modificaciones, cuando construyo obtengo el siguiente error:

Error 383 No se puede copiar el archivo ".. \ root \ leaf \ Bin \ Debug \ test.Resources.xml" a "Bin \ Debug \ test.Resources.xml". Se deniega el acceso a la ruta 'Bin \ Debug \ test.Resources.xml'. li.rollmodel

¿Alguien sabe por qué está ocurriendo este problema?

Editar Puedo ver que toda mi carpeta de código fuente del proyecto es de solo lectura, y no puedo eliminar la propiedad de solo lectura.

Primero, ¿alguien puede decirme cómo eliminar la propiedad de solo lectura para esta carpeta? He intentado eliminarlo pero la propiedad de solo lectura persiste. Intenté desde el lado del control de versiones también y eso tampoco funcionó.

Resolví este problema eliminando los archivos contenciosos de la carpeta bin y reconstruyendo el proyecto.

Solo asegúrese de que la carpeta NO sea de solo lectura y reconstruya la solución

Resolví este problema: cierre Visual Studio, ábralo nuevamente y cargue la solución, reconstruya su solución. Mi problema ocurrió usando TFS y VIsual Studio 2010.

Proceso de matanza VBCSCompiler.exe y reconstruye.

Entré en este problema también.

Primero vaya y verifique si ha asignado su carpeta bin y obj al programa de control de código fuente.

Esto puede convertir sus archivos de carpetas binarias en archivos de solo lectura, lo que hace imposible que Visual Studio los sobrescriba cuando compila el código.

Vaya y elimine la asignación de estas carpetas, verifique los cambios e intente nuevamente.

Mi problema ocurrió usando TFS (Team Foundation Server) y Visual Studio 2010.

Espero que esto ayude a alguien.

Ejecute su Visual Studio como administrador

Yo uso Visual Studio 2013. Enfrenté este problema 2 veces:

1. En la primera ocasión, estaba ejecutando Visual Studio sin derechos de administrador. Entonces, cerré VS y lo comencé usando la opción ' Ejecutar como administrador '. Esto resolvió mi problema.

2. En la segunda ocasión, reinicié VS muchas veces, siempre asegurándome de que lo estaba ejecutando como administrador. Además, reconstruí la solución muchas veces. Pero, a pesar de eso, recibí un error. Después de eso, eliminé el archivo en cuestión de la ubicación de destino (el archivo ya estaba presente puede ser de la compilación anterior en la ubicación donde intenta copiar) y reconstruí la solución . Después de eso, el error desapareció y todo funcionó sin problemas.

En mi caso, fue el antivirus el que bloqueó el archivo.

Esto ha despertado su cabeza nuevamente en Visual Studio 2017, en este caso la causa es el proceso de Application Insights ServiceHub.DataWarehouseHost.exe.

Hay una solución alternativa discutida en el hilo de advertencia MSB3026: No se pudo copiar "obj \ Debug \ netcoreapp1.1 \ src.pdb" a "bin \ Debug \ netcoreapp1.1 \ src.pdb" , que es agregar una precompilación evento al proyecto para matar el proceso cada vez que se construye el proyecto. Citando desde ese enlace:

• Haga clic derecho en las propiedades del proyecto
• Elige propiedades
• Construir eventos
• Línea de comando de evento previo a la compilación

taskkill /IM ServiceHub.DataWarehouseHost.exe /F 2>nul 1>nul
Exit 0

• Guardar y construir

¿Puede alguien saber por qué viene este problema?

Mirando su respuesta de que resolvió su problema copiando manualmente, diría que el código en el que estaba trabajando fue creado por otro usuario (con privilegios de administrador también), por lo que se lo bloqueó. Al realizar copia -? pegue, hizo su PROPIA copia de la fuente con todo el acceso que necesitaba. Lo único que debe notar es que, en este caso, si este otro desarrollador necesita trabajar en su copia, él / ella saltará al mismo problema que tenía antes.

Primero ve a la ubicación del archivo. Luego haga clic derecho en la carpeta del archivo -> Propiedades -> Opción de solo lectura sin marcar y aplique a los archivos y sus subcarpetas. Resolvió mi problema. ¡Feliz codificación!

Volví a agregar todas mis dependencias / referencias ajenas a .NET y funcionó.

Resolví este problema yo mismo. El problema era que tenía la solución abierta en otro lugar. Después de cerrarlo funciona

Tuve el mismo problema, pero reiniciar Visual Studio cada vez no era una opción para mí , ya que el problema ocurre a veces con mucha frecuencia.

Lo manejé instalando Unlocker ( intenta instalar cualquier barra de herramientas en la instalación, así que no olvides desmarcar esto ), esta aplicación me da acceso rápido para renombrar / eliminar un archivo ".xml" bloqueado . Sé que esto también es una solución alternativa, pero para mí fue la solución más rápida para resolver este problema.

Publicación anterior, pero este zombie está llegando a VS 2017 (no he profundizado en por qué son solo "algunos" proyectos). En este caso, no se trata de permisos de usuario , sino que el proceso IIS Express sigue utilizando los archivos.

Verá el ícono en su bandeja de tareas

1. Botón derecho del ratón
2. Salida
3. Debería poder hacerlo rebuildsin este molesto mensaje de "permiso denegado".

Esta es también la razón por la que "reiniciar Visual Studio" "solucionará" el problema. Al hacerlo, se detiene IIS Express.

Hth ...

Creé este problema cuando agregué un nuevo proyecto de instalación a la solución y luego agregué archivos directamente desde la carpeta / bin / release del proyecto de aplicación principal a la carpeta de archivos de la aplicación del proyecto de instalación. El control de origen del proyecto de instalación me impedía constantemente completar una compilación del proyecto de aplicación principal.

Solución: cree una carpeta de volcado separada fuera de cualquiera de los proyectos que contendrá todos los archivos que se incluirán en la instalación, y agréguelos desde allí. Es un dolor porque ahora tengo que recordar copiar todos los archivos para cada nuevo paquete de instalación. Podría ver si puedo hacer algo con las acciones posteriores a la compilación, nuestra compilación automatizada para facilitar el proceso.

Si copia cualquier archivo a una solución, asegúrese de que los archivos no estén en modo de solo lectura. Haga clic derecho en el archivo y desmarque la opción de atributo resuelto mi problema.

Tuve el mismo error pero estoy usando el control de versiones de Perforce . Así es como lo arreglé.

1. Cerrado Perforce P4V cliente
2. Reinicié Visual Studio 2010 (podría no ser necesario)
3. Reconstruyó el proyecto, que tuvo éxito
4. Me sentí excepcionalmente feliz y asqueado al mismo tiempo

También tuve el mismo problema. Recibí mensajes de error relacionados con que no se pueden copiar ya que se denegó el acceso a la ruta. En mi caso, todos mis archivos dll y xml, etc. están ubicados 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 Solo lectura está marcada en Atributos.

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

Regresé 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 hice esto para resolver mi problema.

Verifique el Administrador de tareas y asegúrese de no tener un proceso devenv.exe colgando. Elimina el proceso desbocado e inténtalo de nuevo.

Vaya a la ruta del archivo y luego desmarque la casilla de verificación de solo lectura de este archivo.

Sé que es un hilo antiguo, pero para aquellos que buscan respuestas, como yo hace unos minutos, les recomiendo intentar reiniciar su computadora primero. Eso solo me arregló. Antes ni siquiera podía copiar manualmente a la carpeta.

Simplemente haga clic derecho en su proyecto MVC y haga clic en la opción de limpieza. Tuve un problema similar y la limpieza del proyecto antes de la reconstrucción lo resolvió por mí.

También tuve el mismo problema. Lo arreglé desmarcando las propiedades de solo lectura de la carpeta raíz.

También tuve este problema. Así es como se resuelve esto

• Excluir bincarpeta del proyecto.
• Cerrar estudio visual.
• Limpieza de disco de la unidad C.
• Reabrir proyecto en estudio visual.
• Y luego reconstruir la solución.
• Ejecutar proyecto.

Este proceso me funciona.

Cambiar la ruta de salida funcionó para mí en Visual Studio 2015. Esto debería ayudar: cambiar el directorio de salida de compilación

Pude resolver el problema eliminando el archivo de destino que se queja (en su ejemplo "Bin \ Debug \ test.Resources.xml") de la carpeta bin del sitio web de destino y reconstruirlo. Eso lo arregló para mí.

1) cierre la solución visual studio

2) navegue al símbolo del sistema -> ejecutar como administrador -> iisreset / stop

3) navegue a c -> Windows -> Microsoft.Net -> Framework64 -> v4.030319 -> Archivos temporales de Asp.NET -> Elimine todos los archivos y carpetas en esta ruta.

4) Vuelva a la línea de comandos -> iisreset / start

5) Ahora abra el estudio visual -> ejecute como administrador -> limpie la solución y compílela (no la reconstruya ... solo la compilación funcionó para mí)

Se supone que no debe cambiar el atributo de carpeta a no solo lectura. La razón por la que está viendo este mensaje de error es que el control de origen asume que solo almacena sus archivos misceláneos en otro lugar que no sea la carpeta bin, ya que está reservado para archivos creados automáticamente por .Net y no quiere agregarlos a la fuente controlar.

Sugiero que en lugar de usar Environment.CurrectDirectory(que supongo que está usando actualmente), cree una carpeta llamada "MyProjectName" en la dirección% appdata% y luego use:

System.IO.Path.Combine(Environment.GetEnvironmentVariable("appdata"),"YourProjectName").

Así que me encontré con el mismo problema, la causa mía, compartí mi carpeta de desarrollo para poder usar un mac como host de compilación para una aplicación IOS que usa Xamarin. El proyecto se estaba ejecutando en Mac, que tomó posesión de la DLL, por lo tanto, no pude hacer cambios a esa DLL desde ningún otro lugar. Simplemente detener la aplicación en el Mac me devolvió la propiedad, lo que permitió el acceso completo nuevamente. Espero que esto haga desde entonces.