A criação do Visual Studio falha: não é possível copiar o arquivo exe de obj \ debug para bin \ debug


193

Atualização: Um exemplo de projeto que reproduz esse bug pode ser encontrado aqui no Microsoft Connect . Também testei e verifiquei que a solução dada na resposta aceita abaixo funciona nesse projeto de amostra. Se esta solução não funcionar, você provavelmente está tendo um problema diferente (que pertence a uma pergunta separada).


Essa é uma pergunta feita antes, tanto aqui no Stack Overflow quanto em outros lugares, mas nenhuma das sugestões que encontrei até agora me ajudou, então só tenho que tentar fazer uma nova pergunta.

Cenário: Eu tenho um aplicativo Windows Forms simples (C #, .NET 4.0, Visual Studio 2010). Ele possui alguns formulários básicos dos quais a maioria dos outros herdam, usa o Entity Framework (e as classes POCO) para acesso ao banco de dados. Nada extravagante, sem multi-threading ou qualquer coisa.

Problema: Tudo ficou bem por um tempo. Então, do nada, o Visual Studio falhou ao criar quando eu estava prestes a iniciar o aplicativo. Recebi o aviso "Não foi possível excluir o arquivo '... bin \ Debug \ [ProjectName] .exe'. O acesso ao caminho '... bin \ Debug \ [ProjectName] .exe' foi negado." e o erro "Não é possível copiar o arquivo 'obj \ x86 \ Debug \ [ProjectName] .exe' para 'bin \ Debug \ [ProjectName] .exe'. O processo não pode acessar o arquivo 'bin \ Debug \ [ProjectName] .exe 'porque está sendo usado por outro processo ". (Recebo o aviso e o erro ao executar o Rebuild, mas apenas o erro ao executar o Build - não acha isso relevante?)

Entendo perfeitamente bem o que diz a mensagem de aviso e erro: O Visual Studio está obviamente tentando substituir o arquivo exe enquanto, ao mesmo tempo, possui um bloqueio por algum motivo. No entanto, isso não me ajuda a encontrar uma solução para o problema ... A única coisa que encontrei funcionando é desligar o Visual Studio e iniciá-lo novamente. Construir e lançar funciona, até que eu faça uma alteração em alguns formulários, tenho o mesmo problema novamente e tenho que reiniciar ... Muito frustrante!

Como mencionei acima, esse parece ser um problema conhecido; portanto, existem muitas soluções sugeridas. Vou apenas listar o que já tentei aqui, para que as pessoas saibam o que pular:

  • Criando uma nova solução limpa e copie os arquivos da solução antiga.
  • Adicionando o seguinte ao evento de pré-construção do projeto:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
  • Adicionando o seguinte às propriedades do projeto (arquivo .csproj):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

No entanto, nenhum deles funcionou para mim, então você provavelmente pode ver por que estou começando a ficar um pouco frustrado. Não sei mais para onde procurar, então espero que alguém tenha algo a me dar! Isso é um bug no VS e, se houver, existe um patch? Ou fiz algo errado, tenho uma referência circular ou similar e, em caso afirmativo, como posso descobrir?

Todas as sugestões são muito apreciadas :)

Atualização: Como mencionado no comentário abaixo, também verifiquei, usando o Process Explorer, se realmente é o Visual Studio que está bloqueando o arquivo.


4
Você verificou se o seu aplicativo fecha corretamente? O gerenciador de tarefas mostra [ProjectName] .exe na lista de processos?
miensol

2
Já tive isso antes e simplesmente renomeei o arquivo para .old etc e executei a compilação. Não é exatamente uma correção que eu sei, mas funcionou para mim.
Codingbadger

@miensol: Sim, parece fechar corretamente. Recebo "O programa '[1848] [ProjectName] .vshost.exe: gerenciado (v4.0.30319)' saiu com o código 0 (0x0)." @ Barry: renomear o arquivo exe em bin \ Debug funciona, mas como você disse, não é realmente uma solução e será muito chato ter que fazer o tempo todo. Um pouco melhor do que reiniciar o Visual Studio ...
Julian

2
@ Daliluj: deparei com este artigo em um fórum da Microsoft que explica que ele pode estar relacionado a arquivos de recursos. Se você estiver usando arquivos resx, isso pode dar uma dica.
24410 Patrick

1
Para a posteridade, tive esse problema e foi resolvido adicionando o elemento <GenerateResourceNeverLockTypeAssemblies> true </GenerateResourceNeverLockTypeAssemblies> ao meu arquivo csproj.
ThisIsTheDave

Respostas:


117

Isso vai parecer estúpido, mas eu tentei todas essas soluções, executando o VS2010 no Windows 7. Nenhuma delas funcionou, exceto a renomeação e construção, o que era MUITO entediante, para dizer o mínimo. Eventualmente, localizei o culpado e acho difícil de acreditar. Mas eu estava usando o seguinte código em AssemblyInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

Isso é bastante comum, mas por algum motivo, alterar a versão para 2.0.0.0 fez as coisas funcionarem novamente. Eu não sei se é uma coisa específica do Windows 7 (eu só o uso há 3-4 semanas), ou se é aleatória, ou o quê, mas foi corrigida por mim. Eu estou supondo que o VS estava mantendo um controle sobre cada arquivo gerado, para saber como incrementar as coisas? Eu realmente não tenho certeza e nunca vi isso acontecer antes. Mas se alguém por aí também estiver arrancando os cabelos, tente.


12
Essa é uma ideia maluca, vou lhe dar isso;) O que é ainda mais louco, é que realmente parece funcionar! Eu testei isso várias vezes agora e posso confirmar que, ao usar uma versão de montagem como "2.0. *", Recebo o erro, mas ao usar "2.0.0", ele funciona como um encanto! Peço a mais pessoas que testem isso e, se você achar que está funcionando, vote nesta resposta, porque isso é algo que precisa ser conhecido! Esperança Microsoft levanta esse ... Obrigado drharris :)
Julian

2
isso não funcionou para mim, quando reiniciei o VS não recebi erro por algum tempo. Toda vez que eu recebo esse erro, tenho que reiniciar o VS 2010
Sharique

6
fyi ... isso não funcionou para mim. Minhas configurações sempre foram: [assembly: AssemblyVersion ("1.0.0.0")] [assembly: AssemblyFileVersion ("1.0.0.0")]]
tbone

4
Se você possui atualmente [assembly: AssemblyVersion ("1.0.0.0")], substitua-o por [assembly: AssemblyVersion ("2.0.0.0")]] (ou seja, '2' em vez de '1'). Funcionou para mim. Embora eu não tenha verificado, é possível que simplesmente alterar a versão para algo diferente do que você tem agora possa resolver esse problema.
Frederick The Fool

1
Funciona para DLL também! O VS diz que não é possível copiar a dll e, após alterar AMBOS [assembly: AssemblyVersion] e [assembly: AssemblyFileVersion ()] de 1.0. * Para 2.0.0.0, ele funcionou.
AZ.

14

Como não recebi mais comentários sobre esse problema, pensei em compartilhar o que acabou sendo minha solução:

Conforme sugerido por Barry em um comentário à postagem original, renomear manualmente '... bin \ Debug [ProjectName] .exe' para outra coisa (por exemplo, '[ProjectName] 1.exe' ) é uma solução alternativa (I ' no entanto, não tenho permissão para excluir o arquivo pessoalmente, e devo dizer que acho isso um pouco estranho, pois acreditamos que o mesmo bloqueio que impede a exclusão também impediria a renomeação ...). Não é uma boa solução, mas é razoavelmente rápida (pelo menos depois de fazer isso algumas vezes, quase se torna uma rotina) e, pelo menos, muito mais rápido do que reiniciar o Visual Studio, o que eu fiz no começo.

Caso alguém se pergunte, eu também poderia acrescentar que só vejo esse problema de forma semi-aleatória. Isso geralmente acontece depois que eu faço algumas alterações no modo de design de um formulário (mas nem sempre). Normalmente, isso não acontece se eu alterar apenas o código da lógica de negócios ou o código não visual (mas, às vezes, muda ...). Frustrante, de fato, mas pelo menos eu tenho um truque que funciona para mim - vamos apenas torcer para que meu próximo projeto também não enfrente esse problema ...

@ Barry: se você deseja obter crédito pelo seu comentário, sinta-se à vontade para publicá-lo como resposta e eu aceitarei :)


Eu votei nisso, pois foi o que fiz no passado. Concordo, é uma solução suja, mas funciona. O VS teve esse problema por algumas iterações. Também estou carregando meu projeto de um diretório de rede. Foi totalmente confiável, mas não importa. Não importa se é um mapeamento de unidade ou um UNC. Sim, a MS realmente precisa consertar este. Eles têm um bug fechado por dizer incapaz de se reproduzir. Lame!
Josh Robinson

14

Encontrei uma solução simples, basta desativar o Windows Indexing Services para a pasta e subpastas do projeto


2
Isso funcionou para mim também. Não sei ao certo por que, como o Process Explorer mostrou que o devenv.exe estava segurando a alça de bloqueio. No entanto, desativar a indexação corrigiu o problema.
Fopedush

1
@ Fopedush Encontrei esse problema com a mesma solução, embora não tenha visto essa pergunta no momento. Esta resposta tem algumas explicações sobre por que ajuda.
Darren Hale

1
Este fez isso por mim.
Martin Capodici 26/10/2014

12

Eu tenho o mesmo problema (MSB3021) com o projeto WPF no VS2008 (no Windows 7 x32). O problema aparece se eu tentar executar o aplicativo muito rapidamente após a execução anterior. Depois de alguns minutos, o arquivo exe é desbloqueado por si só e eu posso executar o aplicativo novamente. Mas uma pausa tão longa me irrita. A única coisa que realmente me ajudou foi executar o VS como administrador.


1
Encontrei este relatório de bug recente sobre esse problema exato: connect.microsoft.com/VisualStudio/feedback/details/558848/… Esse relatório de bug forneceu um projeto de exemplo que foi capaz de reproduzir o bug. A solução sugerida por drharris também funcionou lá (consulte a solução alternativa publicada no link acima para obter uma solução passo a passo para o projeto de amostra).
Julian

Esta é a única solução que funcionou para mim também. Obrigado @Nailuj!
Winger

Isso é mais fácil do que reiniciar o VS.
Elvedin Hamzagic

1
"Página não encontrada" para o problema de conexão, eles apenas a excluíram por embaraço = S Houve alguma solução / solução alternativa postada para isso?
Coops

9

Quando me deparei com esse problema, isso tem a ver com o fato de que o projeto que estou tentando criar é definido como o projeto de inicialização na solução, bloqueando o arquivo .exe na pasta obj (também aparece no seu gerenciador de tarefas) clique com o botão direito do mouse em outro projeto na sua solução e escolha definir projeto de inicialização. Isso liberará o bloqueio, o removerá do gerenciador de tarefas e deverá permitir a criação.


1
Isso funciona sempre para mim. Parece ser a ver com o processo vshost que é gerado e começou por serviços
jaywayco

8

Tentei todas as outras sugestões nas respostas aqui, nenhuma das quais funcionou. Eventualmente, usei o Process Monitor para descobrir que meu .exe que o VS2010 estava falhando ao criar estava bloqueado pelo processo do sistema (PID = 4). Pesquisando SO para situações que envolvem isso nessa resposta.

Resumido: se você tiver o serviço Application Experience desativado (como eu fiz), reative-o e inicie-o. Dois anos de agravamento terminaram.


+1 Eu já havia tentado tudo o mais (1. gerenciador de tarefas, 2. explorador de processos, por exemplo, fechar o controle que o Windows não me deixaria fazer, 3. Desativar antivírus, 4. excluindo APP_DATA / Local / Microsoft / Visual Studio do serviço de indexação do Windows. ), mas esta dica é: o serviço "Application Experience" é o único que me salvou batendo minha cabeça contra a parede. Eu o habilitei e o problema desapareceu. O engraçado é que, depois que eu o desativei novamente, tudo ainda estava bem. Não tive mais problemas. Mas, definitivamente, essa é a única coisa que resolveu o problema para mim.
Tomás

Trabalhe para mim também !!! A única outra coisa que funciona também é excluir a pasta bin antes de executar o aplicativo, mas você deve excluir sempre antes da execução, muito irritante.
E_Blue

6

Eu também tive um problema muito semelhante a esse e descobri que, no meu caso, disponibilizei a pasta bin \ debug como uma pasta compartilhada no VMware e VMware, Explorer no convidado da VM ou talvez até um antivírus O programa sob o convidado (embora eu não ache que tenha um instalado) estava segurando um identificador no (s) arquivo (s).


Eu tenho o Avast instalado e esta manhã recebi um erro aleatório do MVC dizendo que minha dll tinha um vírus nele. Após o erro, não era mais possível criar meu projeto MVC. Adicionei uma exceção ao Avast File System Shield e tudo está funcionando novamente.
Dusty


4

Eu sugiro o download Process Explorerpara descobrir exatamente qual processo está bloqueando o arquivo. Pode ser encontrado em:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Eu concordo - não é necessariamente o VS que está bloqueando o arquivo. Os antivírus podem ser culpados disso. Tente desligar o verificador de vírus para ver se isso ajuda.
Polyfun

Desculpe, esqueci de mencionar que já fiz isso. E diz que é o Visual Studio (devenv.exe) que possui um bloqueio no arquivo ([ProjectName] .vshost.exe). Então isso também não me ajuda muito.
Julian

@ShellShock: desativar o meu antivírus (Avast) também não ajuda.
Julian

Para mim, usando o Sysinternals ProcessExplorer, posso ver um identificador para esse arquivo, mas quando clico nele, nenhum aplicativo é mostrado segurando-o e quando tento fechar o identificador, recebo o "Processo de abertura de erro: o identificador é inválido." erro no ProcessExplorer. No entanto, o bloqueio ainda persiste.
tbone

4

Usando o Visual Studio, nunca consegui criar um projeto simples para reproduzir o erro.

Minha solução foi desativar o processo de hospedagem do Visual Studio.

Para os interessados, anexei um rastreamento de identificador para o identificador ofensivo:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

se você vir na parte superior da pergunta, há um link para o Microsoft Connect com um relatório de bug e um projeto de exemplo que reproduz o erro: connect.microsoft.com/VisualStudio/feedback/details/558848/…
Julian

Desabilitar o processo de hospedagem funcionou para mim. Ele continua a funcionar depois de reativá-lo também. Passei 4 horas tentando corrigir esse problema tentando centenas de soluções. Este é o único que parecia remotamente funcionar.
Drew Chapin #

4

SE SEU PROBLEMA NÃO FOR RESOLVIDO AINDA:

O erro do Visual studio é:

"O processo não pode acessar o arquivo 'bin \ Debug ** app.exe **' porque está sendo usado por outro processo."

Então, vá para o gerenciador de tarefas do Windows (Ctrl + Shift + Esc), encontre o nome do aplicativo e force-o a fechar por Endprocces.


3

Aqui está outra possibilidade:

Depois de receber esse erro no vs2012 / win7, tentei excluir o arquivo no diretório bin e o explorer indicou que o arquivo estava em uso pelo XAML UI Designer.

Fechei todas as abas que abri no VS, fechei o VS e, em seguida, certifiquei-me de matar todos os processos do MSBuild no gerenciador de tarefas. Finalmente, depois de reiniciar o VS, consegui criar a solução.


e outra causa possível:

Percebi outra causa possível para esse problema. Após fazer uma refatoração de código, mover projetos para dentro e para fora de uma solução, minhas referências de projeto não estavam mais fazendo referência aos projetos na solução conforme o esperado.

Esse estúdio visual enganou ao pensar que poderia criar alguns projetos simultaneamente, criando os bloqueios de arquivo.

Edição: Eu tive isso acontecer em algumas ocasiões, mesmo recentemente, com o VS2012 e ele corrige uma vez que eu defino a ordem de compilação para as dependências corretas, elimine quaisquer processos de msbuild que o VS deixou em execução e reinicie o VS. Eu mato os processos do msbuild apenas para ter certeza, mas o fechamento do VS também deve eliminá-los.

O que costumo fazer para fazer isso é refatorar um projeto de modo que ele dependa de outro projeto na solução que não estava fazendo referência na última compilação. Às vezes, isso parece confundir o VS e não atualiza a ordem de compilação.

Para verificar a ordem de construção: Clique com o botão direito do mouse na Solução no Gerenciador de Soluções e selecione "Ordem de Construção do Projeto ..." e verifique se as dependências foram anotadas corretamente para cada projeto.


Recentemente, experimentamos isso em um projeto do WinPhone 8. Inexplicavelmente, a causa foi usar o tipo Tuple. Removendo o código que usava uma tupla, o problema desapareceu. Adicione o código de volta ao problema retornado.
Seamus

Eu tive mesmo problema com VS2012, fechando VS não fazer o truque - tem que matar todas as tarefas MSBuild.exe manualmente
mizzle

Estou usando o VS 2013 e consegui simplesmente matar o processo "XDesProc.exe * 32" (Designer de interface do usuário XAML do Microsoft Visual Studio) no gerenciador de tarefas antes de cada compilação e isso foi o que fez o truque. Não há necessidade de reiniciar o VS porque o designer da interface do usuário XAML parece recarregar toda vez que você abre um arquivo * .xaml no modo de design.
Tim Sexton

3

Reiniciar o IIS - pode ser um processo anexado ao depurador


3

Desative o antivírus e tente. Eu também estava enfrentando esse problema ... mas, no meu caso, o antivírus estava bloqueando meu aplicativo quando o desabilitei.


3

Eu enfrentei o mesmo erro.

Resolvi o problema excluindo todo o conteúdo da lixeira pastas de todos os projetos / bibliotecas dependentes.

Este erro ocorre principalmente devido a alterações de versão.



1

Faça as coisas simples primeiro.

Verifique se parte da sua solução não está bloqueada por um processo em execução.

Por exemplo, executei o "InstallUtil 'no meu serviço Windows (que eu normalmente teste de unidade a partir de um console).

Isso bloqueou algumas das minhas DLLs na pasta bin do projeto de serviço do Windows. Quando reconstruí, recebi a exceção nesta edição.

Eu parei o serviço do windows, reconstruído e ele conseguiu.

Verifique o Gerenciador de tarefas do Windows para o seu aplicativo antes de executar qualquer uma das etapas avançadas deste problema.

Então, quando você ouvir passos, pense em cavalos, não em zebras! (do amigo estudante de medicina)


1

Eu tive o mesmo problema. Ele disse que não era possível copiar do bin \ debug para obj .....

Quando eu construo o projeto da web, descobri que minha DLL estava toda na pasta bin e não no bin \ debug. Durante a publicação vs estava procurando arquivos em bin \ debug. Então eu abri o arquivo de projeto da web no editor e procure por instâncias de bin \ debug e encontrei todas as DLLs mencionadas como bin \ debug \ mylibrary.dll. Eu removi tudo \ debug do caminho e publiquei novamente. Desta vez, vs foi capaz de encontrar toda a DLL na pasta bin e publicar com êxito.

Não faço ideia de como esse caminho foi alterado no arquivo de projeto da web.

Passei mais de 5 horas depurando isso e finalmente encontrei a solução por conta própria.

Esta é a resposta certa .


1

Se nenhuma das opções acima funcionar, e você estiver desenvolvendo um aplicativo de console:

Tente digitar qualquer caractere em Program.cs e exclua-o. Não faço idéia do porquê disso funcionar, mas parece resolver o problema 'Não é possível copiar' todas as vezes.


1

Isso geralmente é causado pelo Avast.

Normalmente, eu posso executar meus projetos no Release independentemente, mas ao executar a depuração, ele falha regularmente.

Acabei de adicionar uma exclusão para a minha pasta de projetos e o problema parece desaparecer. Suponho que isso também possa ser causado por outro software antivírus.


1

Renomear o arquivo .exe e .pub funcionou para mim, mas é realmente tedioso. Também enfrento o problema de não poder editar durante uma sessão de depuração. Por fim, fui para a Página de configuração de segurança avançada, conforme:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORKS % 3dV4.0% 22% 29 & rd = true

Desmarque e selecione novamente a caixa de seleção "Ativar configurações de segurança do ClickOnce". Tem sido sem problemas há alguns dias agora ....


1

Para mim, isso estava sendo causado por ter um prompt de comando aberto na pasta de destino (C:\users\username\source\repos\project\project\bin\debug\app.publish ).

Não sei por que DEBUGGING requer acesso à pasta de publicação, mas fechar a janela de comando resolveu o problema para mim.


1

Caso alguém esteja enfrentando isso ao tentar depurar um teste de unidade ou executar um teste de unidade, tive que interromper os dois processos a seguir para liberar o arquivo:

processos para matar.


0

Tentei várias soluções que você forneceu, mas ocasionalmente ainda recebo esse erro. Tenho certeza de que meu processo não está em execução e, quando tento excluir o arquivo executável com o Internet Explorer, ele é removido da lista de arquivos, mas pressiono F5 e pronto, o arquivo está de volta. Não foi excluído.

Mas se eu excluir o arquivo através do TotalCommander, o arquivo exe é realmente excluído e posso criar o projeto com sucesso.

Eu estou usando o Windows 7 x64 e comandante total 7.56a 32 bits.


0

Nenhuma das outras respostas funcionou para mim, mas fechar todas as guias abertas no Visual Studio parece ter resolvido o problema.


0

Sei que essa é uma pergunta muito antiga, mas recentemente tive o erro "não é possível copiar do obj para o bin" no VS 2012. Sempre que tentei reconstruir um determinado projeto, recebi a mensagem. A única solução era fazer uma limpeza antes de cada reconstrução.

Depois de muita investigação, aconteceu que eu tinha uma declaração de aviso de pragma incompleta em um dos meus arquivos que não impedia a compilação de ter êxito, mas estava de alguma forma confundindo o VS em manter os arquivos bloqueados.

No meu caso, eu tinha o seguinte na parte superior do arquivo:

#pragma warning(

É isso aí. Eu acho que estava tentando fazer algo há um tempo e me distraí e nunca terminei o processo, mas os avisos do VS sobre essa linha específica foram perdidos no shuffle. Eventualmente, notei o aviso, removi a linha e recompilei todas as vezes desde então.


0

Quando enfrentei um problema semelhante, a única coisa que parecia funcionar foi:

  • Clique com o botão direito do mouse no projeto, vá para Configurações e verifique se as compilações de Depuração e Liberação têm como destino as mesmas configurações ou têm as configurações que o aplicativo tenta carregar ou salvar.
  • Excluindo a pasta C: \ Users (YourUserAccount) \ AppData \ Local (YourAppName).
  • Certificando-se de que nenhum arquivo que eu tinha lá fosse considerado "Bloqueado". Ao clicar com o botão direito do mouse nos arquivos incluídos no meu projeto, percebi que um ícone estava realmente bloqueado e considerado ruim porque foi baixado da Internet. Eu tive que clicar no botão Desbloquear (por exemplo, verifique isso: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Este arquivo veio de outro computador e pode estar bloqueado para ajudar proteja este computador. ").

0

Para os Serviços do Windows usando o WCF, encerrei o processo do host WFC e funcionou. Eu odeio quando isso acontece, e acontece aleatoriamente às vezes.


0

Minha solução não tem nada a ver com versões, processos sendo bloqueados, reiniciando ou excluindo arquivos.

Na verdade, o problema ocorreu devido à falha na compilação e não ao erro correto. O problema real era uma falha de design:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

Depois de alterar o escopo de "a" para fora da função ou de não usar "a" depois Task.Factory.StartNew();, consegui construir novamente.

Isso aconteceu ao usar a Atualização 4 do VS2012 no Windows7x64 sp1.

Mensagem de erro:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): erro MSB3030: Não foi possível copiar o arquivo "obj \ x86 \ Debug \ xxx.exe" porque não foi encontrado .


0

Eu encontrei com o VS2013, eu recebo esse erro regularmente. Algo que parece funcionar razoavelmente bem é executar uma solução de reconstrução antes de tentar executar o aplicativo. Descobri que executar uma LIMPEZA às vezes funciona, mas a solução de reconstrução parece funcionar de forma mais consistente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.