Build van Visual Studio mislukt: kan exe-bestand niet kopiëren van obj\debug naar bin\debug

Update:Een voorbeeldproject dat deze bug reproduceert, is te vinden hier bij Microsoft Connect. Ik heb ook getest en geverifieerd dat de oplossing gegeven in het geaccepteerde antwoord hieronderwerkt op dat voorbeeldproject. Als deze oplossing niet voor u werkt, heeft u waarschijnlijk een ander probleem (dat in een aparte vraag thuishoort).


Dit is een vraag die eerder is gesteld, zowel hier op Stack Overflow als op andere plaatsen, maar geen van de suggesties die ik tot nu toe heb gevonden heeft me geholpen, dus ik moet gewoon proberen een nieuwe vraag te stellen.

Scenario: ik heb een eenvoudige Windows Forms-toepassing (C#, .NET 4.0, Visual Studio 2010). Het heeft een aantal basisformulieren waarvan de meeste andere formulieren erven, het gebruikt Entity Framework (en POCO-klassen) voor databasetoegang. Niets bijzonders, geen multi-threading of zo.

Probleem: een tijdje ging alles goed. Toen, helemaal uit het niets, kon Visual Studio niet bouwen toen ik op het punt stond de applicatie te starten. Ik kreeg de waarschuwing “Kan bestand ‘…bin\Debug\[ProjectName].exe’ niet verwijderen. Toegang tot het pad ‘…bin\Debug\[ProjectName].exe’ is geweigerd.”en de fout “Kan bestand ‘obj\x86\Debug\[ProjectName].exe’ niet kopiëren naar ‘bin\Debug\[ProjectName].exe’. Het proces heeft geen toegang tot het bestand ‘bin\Debug \[ProjectName].exe’ omdat het door een ander proces wordt gebruikt.”(Ik krijg zowel de waarschuwing als de fout bij het uitvoeren van Rebuild, maar alleen de fout bij het uitvoeren van Build – denk je niet dat dat relevant is? )

Ik begrijp prima wat de waarschuwings- en foutmelding zegt: Visual Studio probeert duidelijk het exe-bestand te overschrijven terwijl het tegelijkertijd om de een of andere reden een vergrendeling heeft. Dit helpt me echter niet om een ​​oplossing voor het probleem te vinden… Het enige wat ik heb gevonden dat werkt, is om Visual Studio af te sluiten en opnieuw te starten. Het bouwen en opstarten werkt dan, totdat ik een wijziging aanbreng in sommige formulieren, dan heb ik hetzelfde probleem en moet ik opnieuw opstarten… Best frustrerend!

Zoals ik hierboven al zei, lijkt dit een bekend probleem te zijn, dus er zijn veel voorgestelde oplossingen. Ik zal hier gewoon opsommen wat ik al heb geprobeerd, zodat mensen weten wat ze moeten overslaan:

  • Maak een nieuwe schone oplossing en kopieer de bestanden van de oude oplossing.

  • Het volgende toevoegen aan het volgende aan de pre-build gebeurtenis van het project:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
        if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
    
  • Het volgende toevoegen aan de projecteigenschappen (.csproj-bestand):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
    

Echter, geen van hen werkte voor mij, dus je kunt waarschijnlijk begrijpen waarom ik een beetje gefrustreerd begin te raken. Ik weet niet waar ik anders moet zoeken, dus ik hoop dat iemand me iets kan geven! Is dit een bug in VS, en zo ja, is er een patch? Of heb ik iets verkeerd gedaan, heb ik een kringverwijzing of iets dergelijks, en zo ja, hoe kom ik daar achter?

Alle suggesties worden zeer op prijs gesteld 🙂

Update:Zoals vermeld in de onderstaande opmerking, heb ik ook met Process Explorer gecontroleerd of het daadwerkelijk isVisual Studio dat het bestand vergrendelt.


Antwoord 1, autoriteit 100%

Dit gaat stom klinken, maar ik heb al deze oplossingen geprobeerd, met VS2010 op Windows 7. Geen van alle werkte behalve het hernoemen en bouwen, wat op zijn zachtst gezegd HEEL vervelend was. Uiteindelijk heb ik de dader opgespoord en ik kan het moeilijk geloven. Maar ik gebruikte de volgende code in AssemblyInfo.cs…

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

Dit komt vrij vaak voor, maar om de een of andere reden zorgde het veranderen van de versie naar 2.0.0.0 ervoor dat alles weer werkte. Ik weet niet of het iets specifieks is voor Windows 7 (ik gebruik het pas 3-4 weken), of dat het willekeurig is, of wat dan ook, maar het loste het voor mij op. Ik vermoed dat VS elk bestand dat het genereerde in de hand hield, zodat het zou weten hoe het dingen moest verhogen? Ik weet het echt niet zeker en heb dit nog nooit eerder zien gebeuren. Maar als iemand anders ook zijn haar uittrekt, probeer het dan eens.


Antwoord 2, autoriteit 12%

Omdat ik geen feedback meer over dit probleem heb gekregen, dacht ik, ik deel gewoon wat uiteindelijk mijn oplossing was:

Zoals gesuggereerd door Barry in een opmerking bij het oorspronkelijke bericht, handmatig de naam van de ‘…bin\Debug[ProjectName].exe’naar iets anders (bijv. ‘[ProjectName] 1.exe’) is een tijdelijke oplossing (ik mag het bestand echter niet zelf verwijderen, en ik moet zeggen dat ik dat een beetje raar vind, omdat je zou denken dat hetzelfde slot dat verwijdering voorkomt ook het hernoemen zou voorkomen …). Het is geen goede oplossing, maar het is redelijk snel (tenminste nadat je het een paar keer hebt gedaan, wordt het bijna een routine), en in ieder geval veel sneller dan het herstarten van Visual Studio, wat ik in het begin deed.

In het geval dat iemand het zich afvraagt, kan ik er ook aan toevoegen dat ik dit probleem slechts semi-willekeurig zie. Het gebeurt meestal nadat ik enkele wijzigingen heb aangebracht in de ontwerpmodus van een formulier (maar niet altijd). Het gebeurt meestal niet als ik alleen bedrijfslogica-code of niet-visuele gerelateerde code verander (maar soms wel…). Frustrerend inderdaad, maar ik heb tenminste een hack die voor mij werkt – laten we hopen dat mijn volgende project niet ook met dit probleem wordt geconfronteerd…

@Barry: als je waardering wilt krijgen voor je reactie, plaats deze dan gerust als antwoord en ik zal ervoor zorgen dat je deze accepteert 🙂


Antwoord 3, autoriteit 12%

Ik heb een simpele oplossing gevonden, schakel gewoon de Windows Indexing Services uit voor de projectmap en submappen


Antwoord 4, autoriteit 10%

Ik heb hetzelfde probleem (MSB3021) met het WPF-project in VS2008 (op Windows 7 x32).
Het probleem treedt op als ik de applicatie te snel opnieuw probeer uit te voeren na de vorige run.
Na een paar minuten wordt het exe-bestand vanzelf ontgrendeld en kan ik de toepassing opnieuw starten. Maar zo’n lange pauze maakt me boos.
Het enige dat me echt hielp was om VS als beheerder te gebruiken.


Antwoord 5, autoriteit 8%

Als ik dit probleem ben tegengekomen, heeft dat te maken met het feit dat het project dat ik probeer te bouwen, is ingesteld als het opstartproject in de oplossing, waardoor de .exe in de obj-map is vergrendeld (het verschijnt ook in uw taak manager,) klik met de rechtermuisknop op een ander project in uw oplossing en kies opstartproject instellen. Dit zal de vergrendeling ontgrendelen, verwijderen uit taakbeheer en je zou moeten laten bouwen.


Antwoord 6, autoriteit 7%

Ik heb alle andere suggesties in de antwoorden hier geprobeerd, maar geen van alle werkte. Uiteindelijk gebruikte ik Process Monitor om te ontdekken dat mijn .exe die VS2010 niet kon bouwen, was vergrendeld door het systeemproces (PID=4). Zoeken met SO naar situaties waarin dit voorkomt, leverde ditantwoord.

Samengevat: als u de Application Experience-service hebt uitgeschakeld (zoals ik deed), schakel deze dan opnieuw in en start deze. Twee jaar van ergernis eindigde.


Antwoord 7, autoriteit 5%

Ik had ook een probleem dat hier erg op leek en ontdekte dat de reden in mijn geval was dat ik de map bin\debug beschikbaar had gemaakt als een gedeelde map onder VMware en ofwel VMware, Explorer onder de VM-gast, of misschien zelfs een anti-virusprogramma onder de guest (hoewel ik niet denk dat ik er een had geïnstalleerd) hield de bestanden vast.


Antwoord 8, autoriteit 4%

Schakel “Schakel het Visual Studio-hostingproces in” uit
Instellingen voor projectfoutopsporing


Antwoord 9, autoriteit 3%

Ik raad aan om Process Explorerte downloaden om erachter te komen welk proces het bestand precies vergrendelt. Het is te vinden op:

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


Antwoord 10, autoriteit 3%

Met Visual Studio zou ik nooit een eenvoudig project kunnen bedenken om de fout te reproduceren.

Mijn oplossing was om het Visual Studio Hosting-proces uit te schakelen.

Voor degenen die geïnteresseerd zijn, heb ik een handgreepspoor voor de gewraakte handgreep bijgevoegd:

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

Antwoord 11, autoriteit 3%

ALS UW PROBLEEM NOG NIET IS OPGELOST:

De fout van Visual Studio is:

“Het proces heeft geen toegang tot het bestand ‘bin\Debug**app.exe**’ omdat het door een ander proces wordt gebruikt.”

Dus, ga naar taakbeheer van windows (Ctrl+Shift+Esc), zoek de naam van je applicatie
en dwing het om te sluiten door Endprocces.


Antwoord 12, autoriteit 3%

Hier is nog een mogelijkheid:

Na het ontvangen van deze fout in vs2012 / win7, ging ik en probeerde het bestand in de bin-map te verwijderen en verkenner gaf aan dat het bestand in gebruik was door de XAML UI Designer.

Ik sloot alle tabbladen die ik had geopend in VS, sloot VS en zorgde er vervolgens voor dat alle MSBuild-processen in taakbeheer werden afgesloten. Eindelijk, nadat ik VS opnieuw had opgestart, kon ik de oplossing bouwen.


en een andere mogelijke oorzaak:

Ik heb een andere mogelijke oorzaak voor dit probleem opgemerkt. Na wat code-refactoring, het verplaatsen van projecten in en uit een oplossing, verwezen mijn projectreferenties niet langer zoals verwacht naar de projecten in de oplossing.

Deze misleidende visuele studio om te denken dat het sommige projecten tegelijkertijd zou kunnen bouwen, waardoor de bestandsvergrendelingen werden gecreëerd.

BEWERK: Ik heb dit een paar keer meegemaakt, zelfs recentelijk met VS2012 en het lost het op zodra ik de bouwvolgorde op de juiste afhankelijkheden heb ingesteld, alle msbuild-processen die VS nog hebben laten draaien, en vervolgens VS opnieuw start. Ik stop de msbuild-processen voor de zekerheid, maar het sluiten van VS zou ze ook moeten uitschakelen.

Wat ik gewoonlijk doe om dit te veroorzaken, is een project zo herstructureren dat het afhankelijk is van een ander project binnen de oplossing waar het niet naar verwees bij de laatste build. Dit lijkt VS soms te verwarren en het werkt de bouwvolgorde niet bij.

Om de bouwvolgorde te controleren: Klik met de rechtermuisknop op de oplossing in de Solution Explorer en selecteer “Projectbouwvolgorde…” en controleer of de afhankelijkheden correct zijn genoteerd voor elk project.


Antwoord 13, autoriteit 3%

Herstart IIS- kan een proces zijn dat aan de debugger is gekoppeld


Antwoord 14, autoriteit 3%

Schakel antivirus uit en probeer het.
Ik had ook met dat probleem te maken… maar in mijn geval blokkeerde antivirus mijn toepassing toen ik antivirus uitschakelde, dat was opgelost.


Antwoord 15, autoriteit 3%

Ik heb met dezelfde fout te maken gehad.

Ik heb het probleem opgelost door alle inhoud van binmappen van alle afhankelijke projecten/bibliotheken te verwijderen.

Deze fout treedt voornamelijk op als gevolg van versiewijzigingen.


Antwoord 16, autoriteit 2%

Dit is meerdere keren ingediend op Connect, de community-site voor het rapporteren van bugs van Microsoft. Ter info, ik geloof dat deze bug sinds 2003 in Visual Studio zit en elke keer na RTM is verholpen. 🙁 Een van de referenties is als volgt:

https://connect.microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.0


Antwoord 17

Doe eerst de simpele dingen.

Controleer of een deel van uw oplossing niet is vergrendeld door een lopend proces.

Ik heb bijvoorbeeld ‘InstallUtil’ uitgevoerd op mijn Windows-service (die ik normaal gesproken test vanaf een console).

Hierdoor werden enkele van mijn dll’s vergrendeld in de bin-map van het Windows-serviceproject.
Toen ik een rebuild deed, kreeg ik de uitzondering in dit probleem.

Ik heb de Windows-service gestopt, opnieuw opgebouwd en het is gelukt.

Controleer Windows Taakbeheer voor uw toepassing, voordat u een van de voorafgaande stappen in deze uitgave uitvoert.

Dus als je voetstappen hoort, denk dan aan paarden en niet aan zebra’s! (van een vriend van een medische student)


Antwoord 18

Ik had hetzelfde probleem. Er stond dat het niet kon kopiëren van bin\debug naar obj…..

Toen ik een webproject bouwde, ontdekte ik dat mijn dll allemaal in de bin-map stond en niet in bin\debug. Tijdens publish vs was op zoek naar bestanden in bin\debug. Dus ik opende het webprojectbestand in de editor en zocht naar exemplaren van bin\debug en ik ontdekte dat alle dll’s werden genoemd als bin\debug\mylibrary.dll. Ik heb alle \debug uit het pad verwijderd en opnieuw gepubliceerd. Deze keer vs was in staat om alle dll’s in de bin-map te vinden en de publicatie is gelukt.

Ik heb geen idee hoe dit pad in het webprojectbestand is gewijzigd.

Ik heb meer dan 5 uur besteed aan het opsporen van fouten en heb uiteindelijk zelf een oplossing gevonden.

Dit is het juiste antwoord.


Antwoord 19

Als geen van bovenstaande werkt en u een consoletoepassing ontwikkelt:

Probeer een willekeurig teken in Program.cs te typen en verwijder het. Ik heb geen idee waarom dit werkt, maar het lijkt elke keer het probleem ‘Kan niet kopiëren’ op te lossen.


Antwoord 20

Dit wordt vrij vaak veroorzaakt door Avast.

Normaal gesproken kan ik mijn projecten hoe dan ook in Release uitvoeren, maar bij het uitvoeren van debug zou het vrij regelmatig mislukken.

Ik voeg gewoon een uitsluiting toe voor mijn projectenmap en het probleem lijkt te verdwijnen. Ik neem aan dat dit ook door andere antivirussoftware kan worden veroorzaakt.


Antwoord 21

Het hernoemen van de .exe- en .pub-bestanden werkte voor mij, maar echt vervelend. Ik heb ook het probleem dat ik tijdens een foutopsporingssessie geen bewerkingen kon uitvoeren. Uiteindelijk ging ik naar de pagina Geavanceerde beveiligingsinstellingen, volgens:

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

Ik deselecteer het en schakel het selectievakje “ClickOnce-beveiligingsinstellingen inschakelen” opnieuw in. Het is al een paar dagen probleemloos….


Antwoord 22

Voor mij werd dit veroorzaakt door het openen van een opdrachtprompt in de doelmap (C:\users\username\source\repos\project\project\bin\debug\app.publish) .

Ik weet niet zeker waarom voor DEBUGGING toegang tot de publicatiemap vereist is, maar het sluiten van het opdrachtvenster loste het probleem voor mij op.


Antwoord 23

In het geval dat iemand dit tegenkomt terwijl hij probeert een eenheidstest te debuggen of een eenheidstest uit te voeren, moest ik de volgende twee processen beëindigen om het bestand vrij te geven:

processen om te doden.


Antwoord 24

Ik heb verschillende oplossingen geprobeerd die je hebt gegeven, maar af en toe krijg ik deze foutmelding nog steeds. Ik ben er zeker van dat mijn proces niet actief is en wanneer ik het uitvoerbare bestand probeer te verwijderen met Internet Explorer, wordt het uit de bestandslijst verwijderd, maar dan druk ik op F5 en voila, het bestand is terug. Het is helemaal niet verwijderd.

Maar als ik het bestand verwijder via de TotalCommander, wordt het exe-bestand daadwerkelijk verwijderd en kan ik het project met succes bouwen.

Ik gebruik Windows 7 x64 en Total Commander 7.56a 32 bit.


Antwoord 25

Geen van de andere antwoorden werkte voor mij, maar het sluiten van alle geopende tabbladen in Visual Studio lijkt het probleem te hebben opgelost.


Antwoord 26

Ik weet dat dit een heel oude vraag is, maar onlangs kreeg ik de foutmelding “kan niet van obj naar bin kopiëren” in VS 2012. Elke keer dat ik probeerde een bepaald project opnieuw op te bouwen, kreeg ik de melding. De enige oplossing was om voor elke herbouw een reiniging te doen.

Na veel onderzoek bleek dat ik een onvolledige pragmawaarschuwingsverklaring in een van mijn bestanden had die de compilatie niet verhinderde, maar op de een of andere manier VS verwarde om de bestanden vergrendeld te houden.

In mijn geval had ik het volgende bovenaan het bestand:

#pragma warning(

Dat is het. Ik denk dat ik een tijdje terug iets probeerde te doen en werd afgeleid en het proces nooit afgemaakt, maar de VS-waarschuwingen over die specifieke regel gingen verloren in de shuffle. Uiteindelijk merkte ik de waarschuwing op, verwijderde de regel en werkte sindsdien elke keer opnieuw.


27

Ik heb gevonden met vs2013 Ik krijg deze fout regelmatig. Iets dat redelijk goed lijkt te werken, is om een ​​rebuild-oplossing uit te voeren voordat u probeert de aanvraag uit te voeren. Ik vond dat het optreden van een schone soms werkt, maar de herbouwoplossing lijkt consequent te werken.

Other episodes