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

Quando eu depurar meu projeto, recebo o seguinte erro:

“Não é 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 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 parado de depurar 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 será executado OK.

Por quê? Como posso corrigir esse erro?

Eu uso o Windows 7 Professional. Com o Xp eu nunca recebi este erro.

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

O que está acontecendo é que o VS está adquirindo um bloqueio em um arquivo e depois não o libera. Ironicamente, esse bloqueio impede que o próprio VS exclua o arquivo para que ele possa recriá-lo quando você reconstruir o aplicativo. A única solução aparente é fechar e reiniciar o VS para liberar o bloqueio no 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. Assim, você pode simplesmente adicionar um número ao final ou algo assim, o que permite que você continue trabalhando sem precisar fechar todas as janelas e esperar que o VS reinicie. Algumas pessoas até o automatizaram usando um evento de pré-compilation para append uma sequência aleatória ao final do nome do arquivo de saída antigo. Sim, esse é um hack gigante , mas esse problema é tão frustrante e debilitante que você faz qualquer coisa.

Mais tarde, aprendi, depois de experimentar um pouco mais, que o problema parece surgir apenas quando você constrói o projeto com um dos designers abertos. Então, a solução que funcionou para mim a longo prazo e me impediu de lidar com um desses erros tolos novamente é garantir que eu sempre feche todas as janelas do designer antes de criar um projeto WinForms. Sim, isso também é um pouco inconveniente, mas com certeza é melhor do que ter que reiniciar VS duas vezes por hora ou mais.

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

Eu também ainda não tentei reproduzi-lo no VS 2012 RC. Não sei se já foi consertado ou não. Mas a minha experiência até agora é que ela ainda consegue aparecer mesmo depois que a Microsoft afirmou que a consertou. 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 há apenas várias causas para o bug e / ou que é muito difícil reproduzir de forma confiável em um laboratório. Essa é a mesma razão pela qual eu não arquivei pessoalmente nenhum relatório de bugs sobre ele (embora eu tenha + 1’ed outros povos), porque eu não consigo reproduzi-lo de forma confiável, como o Abominável Homem das Neves.

Eu tive esse erro aparecendo em mim antes, mesmo no Visual Studio 2008. Ele voltou e prevaleceu mais no Visual Studio 2012.

Aqui está o que eu faço.

Cole isso no evento de pré-compilation 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 de aplicativo

Trabalhou para mim!

Eu tive o mesmo problema no Visual Studio 2013. Não sei o que causou isso no meu projeto, mas consegui corrigi-lo limpando a solução e reconstruindo-a.

  1. Construir> Solução Limpa
  2. Construir> Reconstruir Solução

Pelo menos no meu caso eu notei que o visual studio 2012 estava criando pelo menos dois processos fantasmas msbuild.exe, que não pereceram após a compilation. Esses zumbis aparentemente estão causando bloqueios de arquivos para aparecer.

Killing msbuild.exe é uma solução de tempo, precisa ser feito por base de compilation.

Mas então eu descobri que eu poderia desativar a construção paralela de uma vez por todas – entrou em Ferramentas> Opções> Projetos e Soluções> Construir e Executar> “número máximo de projetos paralelos constrói” – por padrão, tem valor de 8, eu mudei para 1. Funciona como charme.

Claro que as compilações sã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.

Veja minha resposta aqui se você está tendo este problema durante a execução de testes de unidade. Resposta copiada abaixo:

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

 taskkill /f /im vstest.* exit 0 

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

Recentemente, tive um problema com o Visual Studio 2012 com a mesma descrição de erro: “O processo não pode acessar o arquivo porque está sendo usado por outro processo …”

Para corrigir isso primeiro, você precisa entender o aplicativo que ainda o utiliza. Eu desliguei todos os processos como “MSBuild” e “host MSBuild”. Mas isto não é o suficiente. Se você instalou “Code Contracts” e ativou, às vezes, suas DLLs são verificadas e desconectadas dessa operação.

Então, você precisa parar todos os processos de “CCCheck.exe” e isso é tudo.

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

Trabalhou para mim. Gerenciador de Tarefas -> Nome do projeto -> Finalizar tarefa. (eu tinha 3 mesmos processos com o nome do meu projeto);

VS 2013; Ganhar 8;

Certifique-se de que qualquer execução anterior do aplicativo (por exemplo, iniciar sem opção de debugging) esteja realmente parada. Eu estava trabalhando em um aplicativo WPF, iniciado sem debugging e tinha minimizado quando eu continuei recebendo o erro. Depois de fechar o comportamento do aplicativo VS, voltou ao normal.

Eu tenho sido atormentado por esse problema no Visual Studio 2017. Ele começou cerca de duas ou três semanas atrás e prejudicou minha produtividade. Clean and Rebulid não funcionaram; Mesmo reiniciar minha máquina não faz o trabalho.

Uma maneira de lidar com o problema é limpar o assembly problemático e construir (em vez de reconstruir) o projeto que você deseja executar imediatamente depois. Isso funciona cerca de 30% do tempo.

No entanto, provavelmente a solução mais confiável que encontrei é abrir um Prompt de Comando do Desenvolvedor e usar o msbuild diretamente. Eu tenho feito isso nos últimos três dias, e até agora o problema não aconteceu uma vez.

No meu caso, eu habilitei “Mostrar todos os arquivos”. Visual Studio 2017

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

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

Nenhum dos passos acima não resolveu o problema.

Em seguida, abri meu Task Manager e selecionei o processo de dotnet e, em seguida, cliquei no botão Finalizar tarefa. Mais tarde eu abri meu Visual Studio e tudo estava funcionando bem.

insira a descrição da imagem aqui

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

No entanto, eu tenho tido esse problema por um tempo.

Eu vim depois de um tempo para suspeitar de uma interação entre VS e minhas precauções AV.

Depois de algum jogo, parece que ele pode ter desaparecido quando eu modifiquei o meu antivírus para que tudo sob o

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

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

Parece que a compilation realmente grava a DLL aqui primeiro e depois a copia para o local de compilation final.

Pode ser tarde demais. Mas, eu encontrei problema semelhante e no meu caso o projeto tinha auto referência. Por isso, excluí-lo das Referências funcionou como um encanto !!!

Eu encontrei o caminho mais rápido sem fechar formulários ou reiniciar o VisualStudio é ir para a página de compilation do projeto e clique no botão “Advanced Compile Options …”. Em seguida, faça qualquer alteração em uma das opções (por exemplo, alterar Gerar informações de debugging de total para somente pdb) e clique em OK. Ele funciona o tempo todo e terá que fazer até o MS corrigir esse bug (eu nunca tive esse problema até que eu mudei do VS2012 para o VS2013)

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

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

Eu corri para este mesmo problema, e o que eu descobri é que há, na verdade, um aplicativo de formulário do Windows em segundo plano. Isso acontece quando seu aplicativo tem dois formulários e você fecha o segundo formulário que não é seu formulário principal, portanto, o aplicativo não será totalmente encerrado.

Eu costumo executar meu aplicativo

  • através do seu exe ou
  • executar sem debugging

Solução é fechar a outra instância do aplicativo de formulário do Windows . Essa é uma maneira de sempre fechar sua instância do aplicativo.

Comando Pre build

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

Ajudado

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

Estou me aproximando de que você obter esse erro enquanto você estava tentando executar duas janelas formam um após o outro, como primeiro carregar um formulário, em seguida, depois, às vezes, ele desaparecerá automaticamente eo segundo formulário carregado na canvas.

Basicamente, você precisa fechar seu 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 events load form.

  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 depois reconstruí-la. Se isso não funcionar, feche o Visual Studio e vá para a pasta bin \ Debug usando o gerenciador de arquivos. No Coner esquerdo, clique em Arquivo> Abrir Prompt de Comando> Abrir Prompt de Comando como Administrador> Digite este comando “DEL / F / Q / A * “> então reconstruir

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

Para parar 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 Testes em Execução”

Meu problema foi dotnet ficou pendurado e sempre VS iria tentar fazer uma nova dll, ou acessar um antigo, o processo de dotnet iria trancar a dll e parar visual studio de clonagem da dll. A solução é apenas para finalizar todas as tarefas de dotnet no gerenciador de tarefas (ele só removerá o morto, se você estiver tentando finalizar um e não desligar, significa que está funcionando).

Feche o VisualStudio, ctrl-alt-delete, selecione o Gerenciador de Tarefas, localize e finalize todos os processos do MSBuild – o VisualStudio basicamente tem um bug muito severo em que perde o controle do depurador e o depurador mantém um bloqueio no arquivo .pdb no debug / bin pasta. Depois de terminar todos os processos do MSBuild (depurador), exclua a pasta / debug / bin e reabra sua solução no Visual Studio. Você é bom para ir agora. A Microsoft precisa consertar essa porcaria.

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

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

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

(nome do seu projeto) .vbproj

Altere o nome do projeto – como adicionar um -01 ao final. O arquivo .zip original que estava bloqueado ainda está lá, mas não é mais referenciado … para que seu trabalho possa continuar. Na próxima vez em que o computador for reinicializado, esse bloqueio desaparecerá e você poderá excluir o arquivo incorreto.

Intereting Posts