Não foi possível copiar o arquivo - o acesso ao caminho foi negado

Estou usando o Visual Studio 2005. Depois de pegar o código do controle de versão primeiro, o aplicativo c # .net é executado corretamente. Mas, depois de fazer algumas modificações, ao criar, estou recebendo o seguinte erro:

Erro 383 Não foi possível copiar o arquivo ".. \ root \ leaf \ Bin \ Debug \ test.Resources.xml" para "Bin \ Debug \ test.Resources.xml". O acesso ao caminho 'Bin \ Debug \ test.Resources.xml' foi negado. li.rollmodel

Alguém sabe por que esse problema está ocorrendo?

Editar Posso ver que toda a minha pasta de código-fonte do projeto é somente leitura e não consigo remover a propriedade somente leitura.

Primeiro, alguém pode me dizer como remover a propriedade Somente leitura para esta pasta? Eu tentei removê-lo, mas a propriedade somente leitura persiste. Também tentei do lado do controle de versão e isso também não funcionou.

Resolvi esse problema excluindo os arquivos contenciosos da pasta bin e reconstruindo o projeto.

Apenas verifique se a pasta NÃO é somente leitura e reconstrua a solução

Resolvi este problema: Feche o Visual Studio, abra-o novamente e carregue a solução, Reconstrua sua solução. Meu problema ocorreu usando o TFS e o VIsual Studio 2010.

Finalize o processo VBCSCompiler.exee reconstrua.

Eu pisei nesse problema também.

Primeiro, verifique se você mapeou sua pasta bin e obj para o programa Source Control.

Isso pode transformar os arquivos das pastas de binários em arquivos somente leitura, o que torna impossível para o visual studio substituí-los quando compila o código.

Vá e remova o mapeamento dessas pastas, verifique as alterações e tente novamente.

Meu problema ocorreu usando o TFS (Team Foundation Server) e o Visual Studio 2010.

Espero que isso ajude alguém.

Execute seu Visual Studio como administrador

Eu uso o Visual Studio 2013. Eu enfrentei esse problema 2 vezes:

1. Na primeira ocasião, eu estava executando o Visual Studio sem direitos de administrador. Então, fechei o VS e o iniciei usando a opção ' Executar como administrador '. Isso resolveu meu problema.

2. Na segunda ocasião, reiniciei o VS várias vezes, sempre certificando-me de que estou executando-o como administrador. Além disso, reconstruí a solução várias vezes. Mas, apesar disso, estava recebendo erro. Depois disso, removi o arquivo em questão do local de destino (o arquivo já estava presente pode ser da compilação anterior no local em que ele tenta copiar) e reconstruí a solução . Depois disso, o erro desapareceu e tudo correu bem!

No meu caso, foi o antivírus que bloqueou o arquivo.

Isso elevou sua cabeça novamente no Visual Studio 2017; nesse caso, a causa é o processo do Application Insights ServiceHub.DataWarehouseHost.exe.

Há uma solução alternativa discutida no aviso de thread MSB3026: Não foi possível copiar "obj \ Debug \ netcoreapp1.1 \ src.pdb" para "bin \ Debug \ netcoreapp1.1 \ src.pdb" , que é adicionar uma pré-compilação evento ao projeto para interromper o processo toda vez que o projeto for construído. Citando a partir desse link:

• Clique com o botão direito do mouse nas propriedades do projeto
• Escolha propriedades
• Construir Eventos
• Linha de comando do evento de pré-construção

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

• Salvar e construir

Alguém pode saber por que esse problema está chegando?

Analisando sua resposta de que você resolveu seu problema através de cópia manual, eu diria que o código em que você estava trabalhando foi criado por outro usuário (com privilégios de administrador também), por isso estava bloqueado para você. Executando cópia -? colar, você fez sua PRÓPRIA cópia da fonte com todo o acesso necessário. A única coisa a se notar é que, nesse caso, se esse outro desenvolvedor precisar trabalhar na sua cópia, ele / ela entrará no mesmo problema que você teve antes.

Primeiro, vá para o local do arquivo. Em seguida, clique com o botão direito do mouse na pasta do arquivo -> Propriedades -> Opção Somente Leitura Desmarcada e aplique aos arquivos e suas subpastas. Resolveu o meu problema. Feliz codificação!

Eu adicionei novamente todas as minhas dependências / referências que não são do .NET e ele fez o truque.

Eu mesmo resolvi esse problema. O problema era que a solução foi aberta em outro local. Depois de fechá-lo, funciona

Tinha o mesmo problema, mas reiniciar o Visual Studio toda vez não era uma opção para mim , pois o problema ocorre às vezes com muita frequência.

Eu lidei com isso instalando o Unlocker ( tenta instalar qualquer barra de ferramentas na instalação, por isso não se esqueça de desmarcar isso ), este aplicativo me dá acesso rápido para renomear / excluir um arquivo ".xml" bloqueado . Eu sei que isso também é uma solução alternativa também, mas para mim foi a solução mais rápida para resolver esse problema.

Post antigo, mas esse zumbi está chegando ao VS 2017 (eu não expliquei por que são apenas "alguns" projetos). Nesse caso, não são permissões de usuário , mas o processo do IIS Express ainda está usando os arquivos.

Você verá o ícone na bandeja de tarefas

1. Clique com o Botão Direito
2. Saída
3. Você deve poder rebuildsem essa mensagem irritante de "permissão negada".

É também por isso que "reiniciar o Visual Studio" irá "corrigir" o problema. Fazendo isso, interrompe o IIS Express.

Hth ...

Criei esse problema quando adicionei um novo projeto de instalação à solução e adicionei arquivos diretamente da pasta / bin / release do projeto principal do aplicativo à pasta de arquivos do aplicativo do projeto de instalação. O controle de origem do projeto de instalação estava constantemente me impedindo de concluir a compilação do projeto principal do aplicativo.

Solução: crie uma pasta de despejo separada fora de qualquer um dos projetos que conterá todos os arquivos a serem incluídos na instalação e adicione-os a partir daí. É uma dor, porque agora tenho que lembrar de copiar todos os arquivos para cada novo pacote de instalação. Talvez eu veja se consigo fazer algo com as ações pós-compilação ou uma compilação automatizada para tornar o processo mais suave.

Se você copiar qualquer arquivo para uma solução, verifique se os arquivos não estão no modo Somente Leitura. Clique com o botão direito do mouse no arquivo e desmarque a opção de atributo resolvido meu problema.

Eu tive o mesmo erro, mas estou usando o controle de versão do Perforce . Aqui está como eu consertei.

1. Fechado Perforce P4V cliente
2. Reiniciado o Visual Studio 2010 (pode não ser necessário)
3. Reconstruiu o projeto, que teve sucesso
4. Senti-me excepcionalmente feliz e enojado ao mesmo tempo

Eu também tive o mesmo problema. Recebi mensagens de erro relacionadas a não podem ser copiadas, pois o acesso ao caminho foi negado. No meu caso, todos os meus arquivos DLL e XML, etc., estão na pasta D: \ TFS \ Example \ Bin \ Debug.

Clique com o botão direito do mouse na pasta Bin, clique em Propriedades e vi que a caixa de seleção Somente leitura está marcada em Atributos.

Desmarquei a caixa de seleção Somente leitura e clicou em Aplicar e clicou em OK no novo pop-up mostrado.

Voltei ao Visual Studio e criei minha solução, que estava me dando mensagens de erro.

Voilaa .. Desta vez, ele foi criado com sucesso, sem erros.

Não sei se isso é perfeito, mas fiz isso para resolver meu problema.

Verifique o Gerenciador de tarefas e verifique se você não tem um processo devenv.exe travado. Mate o processo descontrolado e tente novamente.

Vá para o caminho do arquivo e desmarque a caixa de seleção somente leitura deste arquivo.

Eu sei que é um tópico antigo, mas para aqueles que procuram respostas, como eu há alguns minutos, recomendo tentar reiniciar o computador primeiro. Isso por si só consertou. Antes não podia nem copiar manualmente para a pasta.

Apenas clique com o botão direito do mouse no seu projeto MVC e clique na opção limpa. Eu tive um problema semelhante e a limpeza do projeto antes da reconstrução o resolveu para mim.

Eu também tive o mesmo problema. Corrigi-o desmarcando as propriedades Somente leitura da pasta raiz.

Eu também tive esse problema. Aqui está como é resolvido isso

• Excluir binpasta do projeto.
• Feche o estúdio visual.
• Limpeza de disco da unidade C.
• Reabra o projeto no visual studio.
• E, em seguida, recrie a solução.
• Execute o projeto.

Esse processo funciona para mim.

Alterar o caminho de saída funcionou para mim no Visual Studio 2015. Isso deve ajudar - Alterando o diretório Build Output

Consegui resolver o problema removendo o arquivo de destino que está reclamando (no seu exemplo "Bin \ Debug \ test.Resources.xml") da pasta bin do site de destino e construí-lo. Isso foi corrigido por mim.

1) feche a solução do visual studio

2) navegue até o prompt de comando -> execute como administrador -> iisreset / stop

3) navegue até c -> Windows -> Microsoft.Net -> Framework64 -> v4.030319 -> Arquivos temporários de Asp.NET -> Exclua todos os arquivos e pastas nesse caminho.

4) Navegue de volta ao prompt de comando -> iisreset / start

5) Agora abra o visual studio -> execute como administrador -> limpe a solução e construa-a (não reconstrua .. apenas a compilação funcionou para mim)

Você não deve alterar o atributo da pasta para não somente leitura. O motivo pelo qual você está vendo essa mensagem de erro é que o controle de origem pressupõe que você armazena apenas seus arquivos diversos em outro lugar que não seja a pasta bin, pois é reservado para arquivos criados automaticamente pelo .Net e não deseja adicioná-los à origem ao controle.

Sugiro que, em vez de usar Environment.CurrectDirectory(que suponho que você esteja usando atualmente), crie uma pasta chamada "MyProjectName" no endereço% appdata% e use:

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

Então, acabei de encontrar o mesmo problema, a causa minha, compartilhava minha pasta de desenvolvimento para poder usar um mac como host de construção para um aplicativo IOS usando o Xamarin. O projeto estava sendo executado no mac, que tomou posse da dll, portanto, não pude fazer alterações nessa dll de qualquer outro lugar. Simplesmente parar o aplicativo no mac retornou a propriedade para mim, o que permitiu o acesso total novamente. Espero que isso faça desde então.