Erro: Não é possível acessar o arquivo bin / Debug /… porque ele está sendo usado por outro processo

Quando depuro meu projeto, recebo o seguinte erro:

"Não foi possível copiar o arquivo" obj \ Debug \ My Dream.exe "para" bin \ Debug \ My Dream.exe ". O processo não pode acessar o arquivo 'bin \ Debug \ My Dream.exe' porque ele está sendo usado por outro processo."

Usando o Process Explorer, vejo que MyApplication.exe estava fora, mas o processo do sistema ainda o usa, embora eu tenha interrompido a depuração antes. Sempre que eu mudar meu código e começar a depurar, isso vai acontecer. Se eu copiar o projeto para USB e depurar, ele funcionará bem.

Por quê? Como posso corrigir esse erro?

Eu uso o Windows 7 Professional. Com o XP nunca recebi esse erro.

Ugh, esse é um problema antigo, algo que ainda aparece no Visual Studio de vez em quando. Ele me mordeu algumas vezes e perdi horas reiniciando e lutando com o VS. Tenho certeza de que já foi discutido aqui no SO mais de uma vez. Também foi falado nos fóruns do MSDN. Não existe uma solução real, mas existem algumas soluções alternativas. Comece a pesquisar aqui .

O que está acontecendo é que o VS está obtendo um bloqueio em um arquivo e, em seguida, não o libera. Ironicamente, esse bloqueio impede o próprio VS de excluir o arquivo para que possa recriá-lo quando você reconstruir o aplicativo. A única solução aparente é fechar e reiniciar o VS para que ele libere o bloqueio do arquivo.

Minha solução original foi abrir a pasta bin / Debug e renomear o executável. Você não pode excluí- lo se estiver bloqueado, mas pode renomeá-lo. Então você pode simplesmente adicionar um número ao final ou algo assim, o que permite que você continue trabalhando sem ter que fechar todas as suas janelas e esperar que o VS reinicie. Algumas pessoas até automatizaram isso usando um evento de pré-criação para anexar uma string aleatória ao final do antigo nome de arquivo de saída. Sim, este é um hack gigante , mas esse problema se torna tão frustrante e debilitante que você fará qualquer coisa.

Mais tarde, aprendi, após um pouco mais de experimentação, que o problema parece surgir apenas quando você constrói o projeto com um dos designers aberto. Portanto, a solução que funcionou para mim a longo prazo e me impediu de lidar com um desses erros idiotas novamente é ter certeza de que sempre fechei todas as janelas de designer antes de construir um projeto WinForms. Sim, isso também é um tanto inconveniente, mas com certeza é melhor do que reiniciar o VS duas vezes por hora ou mais.

Presumo que isso se aplique ao WPF também, embora eu não o use e não tenha experimentado pessoalmente o problema lá.

Eu também não tentei reproduzi-lo no VS 2012 RC. Não sei se já foi consertado ou não. Mas minha experiência até agora tem sido que ele ainda consegue aparecer mesmo depois que a Microsoft alegou que o corrigiu. Ainda está lá no VS 2010 SP1. Não estou dizendo que seus programadores são idiotas que não sabem o que estão fazendo, é claro. Eu acho que existem várias causas para o bug e / ou que é muito difícil reproduzi-lo de forma confiável em um laboratório. Essa é a mesma razão pela qual eu não preenchi pessoalmente nenhum relatório de bug sobre ele (embora eu tenha marcado outras pessoas com +1), porque eu não consigo reproduzi-lo de maneira confiável, como o Abominável Homem das Neves.

_{<fim do discurso que não é dirigido a ninguém em particular>}

Este erro já apareceu em mim antes, mesmo no Visual Studio 2008. Ele voltou e prevaleceu no Visual Studio 2012.

Aqui está o que eu faço.

Cole isso no evento de pré-construção do projeto problemático:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Computador (clique com o botão direito) -> gerenciar -> Serviço e aplicativo -> serviço -> Ativar experiência do aplicativo

Funcionou para mim!

Tive o mesmo problema no Visual Studio 2013. Não tenho certeza do que causou isso no meu projeto, mas consegui consertar limpando a solução e reconstruindo-a.

1. Build> Clean Solution
2. Build> Rebuild Solution

Pelo menos no meu caso, notei que o visual studio 2012 estava criando pelo menos dois processos fantasmas msbuild.exe, que não morreram após a compilação. Aparentemente, esses zumbis estão causando o aparecimento de bloqueios de arquivos.

Eliminar o msbuild.exe é uma solução única e precisa ser feito por build.

Mas então descobri que poderia desabilitar a construção paralela de uma vez por todas - entrei em Ferramentas> Opções> Projetos e soluções> Construir e executar> "número máximo de construções paralelas de projeto" - por padrão, tem o valor 8, I mudei para 1. Funciona perfeitamente.

Claro que as compilações estão um pouco mais lentas agora, mas é melhor prevenir do que remediar. Pelo menos para este pequeno projeto em particular, não precisei de mais de um thread de construção.

Eu entendo que esta é uma questão antiga. Infelizmente, eu estava enfrentando o mesmo problema com meu .net core 2.0aplicativo em visual studio 2017. Então, pensei em compartilhar a solução que funcionou para mim. Antes desta solução, experimentei os passos abaixo.

1. Estúdio visual reiniciado
2. Fechou todo o aplicativo
3. Limpe minha solução e reconstrua

Nenhuma das etapas acima não corrigiu o problema.

E então eu abri meu processo Task Managerselecionado dotnete cliquei no botão Finalizar tarefa. Mais tarde, abri meu Visual Studio e tudo estava funcionando bem.

Veja minha resposta aqui se você estiver tendo esse problema ao executar testes de unidade. Resposta copiada abaixo:

Com base na resposta de Sébastien, adicionei uma etapa de pré-construção ao meu projeto de teste para matar automaticamente todos os vstest.*executáveis ​​ainda em execução. O seguinte comando de pré-construção funcionou para mim:

taskkill /f /im vstest.*
exit 0

O exit 0comando está no final para evitar falha de compilação quando não há vstest.*executáveis ​​em execução.

Recentemente, tive problemas com o Visual Studio 2012 com a mesma descrição de erro: "O processo não pode acessar o arquivo porque ele está sendo usado por outro processo ..."

Para corrigir isso, primeiro você precisa entender o aplicativo que ainda o utiliza. Desliguei todos os processos como "MSBuild" e "host MSBuild". Mas isto não é o suficiente. Se você instalou "Code Contracts" e o ativou, às vezes leva suas DLLs para verificar e desligar nesta operação.

Portanto, você precisa interromper todos os processos de "CCCheck.exe" e pronto.

Finalmente, para entender que o processo está usando sua DLL, você sempre pode tentar apenas Excluir a pasta "obj" em seu Gerenciador de Arquivos e esta operação irá falhar, você pode ver a "Janela de Mensagem" com a descrição da operação de suspensão. Além disso, como variante, você pode tentar usar o aplicativo "Sys Internals Suite".

Funcionou para mim. Gerenciador de tarefas -> Nome do projeto -> Finalizar tarefa. (tive 3 processos iguais com o nome do meu projeto);

VS 2013; Win 8;

Certifique-se de que qualquer execução anterior do aplicativo (por exemplo, iniciar sem a opção de depuração) foi realmente interrompida. Eu estava trabalhando em um aplicativo WPF, comecei sem depuração e o minimizei quando continuei recebendo o erro. Após fechar o aplicativo, o comportamento do VS voltou ao normal.

Tenho sido atormentado por esse problema no Visual Studio 2017. Ele começou há cerca de duas ou três semanas e prejudicou minha produtividade. Clean e Rebulid não funcionaram; mesmo reiniciar minha máquina não funciona.

Uma maneira de lidar com o problema é limpar a montagem problemática e construir (em vez de reconstruir) o projeto que deseja executar imediatamente depois. Isso funciona cerca de 30% das vezes.

No entanto, provavelmente a solução mais confiável que encontrei é abrir um prompt de comando do desenvolvedor e usar msbuilddiretamente. Venho fazendo isso há três dias e até agora o problema não aconteceu nenhuma vez.

No meu caso foi que habilitei "Mostrar todos os arquivos". Visual Studio 2017

Corra taskmanager.
Localize netcoree exclua-o.
Em seguida, você pode excluir o arquivo manualmente ou executando Clean.

Isso é pura especulação e não uma resposta.

No entanto, estou tendo esse problema há algum tempo.

Depois de um tempo, suspeitei de uma interação entre o VS e minhas precauções AV.

Depois de jogar, parece que pode ter ido embora quando eu modifiquei meu antivírus para que tudo sob o

C: \ Usuários [nome de usuário] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

pasta não foi incluída na proteção em tempo real.

Parece que a construção realmente grava a DLL aqui primeiro e, em seguida, a copia para o local de construção final.

Pode ser tarde demais. Porém, encontrei problema semelhante e no meu caso o projeto tinha autorreferência. Portanto, excluí-lo das referências funcionou perfeitamente !!!

Eu descobri que a maneira mais rápida sem fechar formulários ou reiniciar o VisualStudio é ir para a página de compilação do projeto e clicar no botão "Opções avançadas de compilação ...". Em seguida, faça qualquer alteração em uma das opções (por exemplo, alterando Gerar informações de depuração de Completo para somente PDB) e clique em OK. Funciona sempre e terá que funcionar até a MS corrigir esse bug (nunca tive esse problema até mudar de VS2012 para VS2013)

Outra observação, se você não puder limpar o projeto ou solução, ele não será compilado. Os arquivos estão definitivamente bloqueados pelo VS (não é um problema de antivírus, pelo menos não no meu caso)

Tentei todas essas sugestões, bem como outras sugestões encontradas em outros lugares e a única coisa que funcionou para mim foi reiniciar meu computador. Então fiz uma solução limpa seguida de reconstrução. Estou usando o Visual Studio 2013 para referência.

Eu corri para o mesmo problema, e o que descobri é que, na verdade, há vários aplicativos de formulário do Windows em execução em segundo plano. Acontece quando a sua aplicação possui dois formulários e você fecha o 2º formulário que não é o seu formulário principal, para que a aplicação não saia totalmente.

Eu geralmente executo meu aplicativo

• através de seu exe ou
• executar sem depuração

A solução é fechar a outra instância do aplicativo Windows Form . Essa é uma maneira de sempre fechar a instância do aplicativo.

Comando de pré-construção

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Ajudou

[Resolvido] Erro: Não é possível acessar o arquivo bin / Debug / ... porque ele está sendo usado por outro processo:

Estou me aproximando de que você recebe este erro enquanto tenta executar duas janelas de forma uma após a outra, como primeiro o carregamento de um formulário e, às vezes, ele desaparece automaticamente e o segundo formulário é carregado na tela.

Basicamente, você precisa fechar o primeiro formulário que está sendo executado em segundo plano e a principal razão por trás desse erro.

Para fechar o primeiro formulário, você deve adicionar essas duas linhas de código no segundo manipulador de eventos de carregamento do formulário.

    Form1 form = new Form1();
    form.Close();

Isso resolverá o erro perfeitamente.

Uma solução simples é ir para a pasta bin \ Debug, excluir todos os arquivos dessa pasta e, em seguida, reconstruir. Se não funcionar, feche o Visual Studio e vá para a pasta bin \ Debug usando o explorador de arquivos, no ícone esquerdo, clique em Arquivo> Abrir Prompt de Comando> Abrir Prompt de Comando como Administrador> Digite este comando "DEL / F / Q / A * "> então reconstruir

Achei a resposta de Cody Gray parcialmente útil, na medida em que me direcionou para a fonte real do meu problema que alguns de vocês também podem estar enfrentando: a execução do teste do Visual Studio permanece aberta por padrão e mantém um bloqueio nos arquivos.

Para interromper esse comportamento predominantemente inútil, siga as instruções de https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 -50727-1-rtmrel

Desmarque o menu Teste -> Configurações de teste -> "Manter o mecanismo de execução de teste em execução"

Meu problema era que o dotnet travava e sempre que o VS tentava fazer uma nova dll ou acessava uma antiga, o processo dotnet travava na dll e impedia o visual studio de cloná-la. A solução é apenas encerrar todas as tarefas dotnet no gerenciador de tarefas (ele só removerá realmente a que está morta, se você estiver tentando encerrar uma e não desligar, isso significa que está funcionando).

Feche o VisualStudio, ctrl-alt-delete, selecione o Gerenciador de tarefas, encontre e encerre todos os processos do MSBuild - o VisualStudio basicamente tem um bug bastante grave em que perde o controle de seu depurador e o depurador mantém um bloqueio no arquivo .pdb no depurador / bin pasta. Depois de encerrar todos os processos MSBuild (depurador), exclua a pasta / debug / bin e reabra sua solução no Visual Studio. Você está pronto para ir agora. A Microsoft precisa consertar essa porcaria.

Eu abri uma pergunta separada sobre o VS 2017 que teve um comportamento semelhante após uma atualização. O problema parecia ser gerado pelo programa antivírus.

Eu adicionei a pasta bin à lista de exclusão do antivírus, reiniciei a máquina e agora parece funcionar.

Eu resolvi esse problema ..

próximo ao debug, você verá o menu suspenso com algumas configurações. O padrão era Qualquer CPU. Selecione x86 e execute o programa que funcionará. Se o x86 não ir ao gerenciador de configuração e adicionar o x86

Outro kludge, ugh, mas é fácil e funciona para mim no VS 2013. Clique no projeto. No painel de propriedades deve haver uma entrada chamada Arquivo de projeto com um valor

(nome do seu projeto) .vbproj

Altere o nome do projeto - como adicionar -01 ao final. O arquivo .zip original que estava bloqueado ainda está lá, mas não mais referenciado ... então seu trabalho pode continuar. Na próxima vez que o computador for reiniciado, o bloqueio desaparecerá e você poderá excluir o arquivo incorreto.