Visual Studio 2010 gebruiken, wanneer ik in korte tijd in korte intervallen bouwt, krijg ik vaak de volgende fout. Als ik net een minuut of twee wacht en probeer het opnieuw goed. Unlocker Claims Geen handgreep vergrendelt het uitvoerbare bestand.
Hoe kan ik ontdekken wat er is? < br>Als het visuele studio zelf is, wat moet ik doen om het te laten stoppen? of alternatief om het bestand vrij te geven?
1>------ Build started: Project: MyProj, Configuration: Release Win32 ------
...
1>InitializeBuildStatus:
1> Creating "Release\MyProj.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> SomeFile1.cpp
1>ResourceCompile:
1> All outputs are up-to-date.
1>LINK : fatal error LNK1104: cannot open file 'D:\...\MyProj.exe'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.94
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Antwoord 1, Autoriteit 100%
Had dit probleem na een herinstallatie vandaag opnieuw. Zorg ervoor dat de service-ervaring wordt gestart en niet ingesteld op Uitgeschakeld. Als de handleiding is ingesteld, denk ik dat VS zal beginnen.
Antwoord 2, Autoriteit 38%
Ik ben me ervan bewust dat dit vrij oud is, maar ik had net hetzelfde probleem met Visual Studio 2010 allemaal gepatcht, zodat anderen hier nog steeds tegen zijn.
Mijn projectpad toevoegen aan “Uitgesproken items” in My AVG Anti-Virus-instellingen lijkt het probleem voor mij te hebben opgelost.
Probeer een antivirus / resident-scherm uit te schakelen en te zien of deze het probleem oplost. Als dit het geval is, voegt u uw projectpad toe aan uitgesloten mappen in uw AV-configuraties.
Antwoord 3, Autoriteit 36%
Je had waarschijnlijk een verdwaald bouwproces dat het uitvoerbare bestand blokkeerde, en het (het verdwaalde proces) werd niet opgeschoond. In dat geval, sluit Visual Studio af, open Process Explorer en vernietig elk proces dat je kunt vinden dat gerelateerd is aan Visual Studio.
Open vervolgens de visuele studio opnieuw en probeer uw project opnieuw op te bouwen.
Antwoord 4, autoriteit 13%
het bestand kan worden vergrendeld omdat het nu wordt uitgevoerd. Probeer het proces te beëindigen met een taakbeheerder.
Antwoord 5, autoriteit 13%
Zoals Jonathan al zei, ja, hernoemen kan helpen om dit probleem te omzeilen. Maar bijv. Ik was vaak gedwongen om het uitvoerbare bestand van het doel te hernoemen, het is een beetje vervelend en niet goed.
Het probleem is dat wanneer u uw project uitvoert en later een foutmelding krijgt dat u uw project niet kunt bouwen, dit komt omdat dit uitvoerbare bestand (uw project) nog steeds actief is (u kunt het controleren via taakbeheer.)
Als je gewoon de naam van de build van het doel hernoemt, krijg je enige tijd later dezelfde foutmelding met een nieuwe naam en als je een taakbeheer opent, zul je zien dat je systeem vervuilt met je niet voltooide projecten.
Visual studio voor het maken van een nieuwe build moet het vorige uitvoerbare bestand verwijderen en nieuw maken in plaats van oud, het kan dit niet doen terwijl het uitvoerbare bestand nog draait. Dus als je een nieuwe build wilt maken, moet het proces van het oude uitvoerbare bestand worden gesloten! (het is vreemd dat Visual Studio het niet vanzelf sluit en ja, het lijkt op wat buggy-gedrag).
Het is een beetje vervelend om het handmatig te doen, dus je kunt gewoon een bat-bestand gebruiken en erop klikken als je een dergelijk probleem hebt:
taskkill /f /im name_of_target_executable.exe
het werkt in ieder geval voor mij.
Zoals een gok – ik sluit mijn programma niet goed af in C++, dus misschien is het normaal dat Visual Studio het laat draaien.
AANVULLING:
De kans is groot dat dit wel het geval is, omdat de aanvraag nog niet is afgerond. Controleer of je uiteindelijk PostQuitMessage hebt gebeld, om Windows te laten weten dat je klaar bent.
Antwoord 6, autoriteit 10%
Misschien hebt u de uitvoer niet gesloten. Sluit de uitvoer, maak het bestand schoon en bouw het opnieuw op. Mogelijk kunt u het bestand nu uitvoeren.
Antwoord 7, autoriteit 5%
Ik ben tot de conclusie gekomen dat dit een soort Visual Studio-bug is. Misschien heeft C Johnson gelijk – misschien houdt het bouwproces het bestand vergrendeld.
Ik heb een tijdelijke oplossing die werkt – elke keer dat dit gebeurt – verander ik de doelnaam van het uitvoerbare bestand onder de eigenschappen van het project (klik met de rechtermuisknop op het project en vervolgens op Eigenschappen\Configuratie-eigenschappen\Algemeen\Doelnaam).
Op deze manier creëert VS een nieuw uitvoerbaar bestand en wordt het probleem omzeild. Om de paar keer dat ik dit doe, keer ik terug naar de oorspronkelijke naam, dus fiets ik door ~3 namen.
Als iemand de reden hiervoor en een oplossing kan vinden, geef dan alstublieft antwoord en ik kan het antwoord naar het uwe verplaatsen, aangezien de mijne een tijdelijke oplossing is.
Antwoord 8, autoriteit 5%
Ik had hetzelfde probleem, echter met Codeblocks. Vanwege dit probleem stopte ik met programmeren omdat ik elke keer mijn computer uit het raam wilde gooien.
Ik wil user963228 bedanken wiens antwoord daar echt een oplossing voor is. U moet Application Experience op Handmatig opstarten zetten (u kunt dit doen door services te zoeken in het startmenu van Windows 7 en vervolgens Application Experience te zoeken en op eigenschappen te klikken).
Dit probleem doet zich voor wanneer mensen hun Windows 7-machine willen aanpassen en besluiten een aantal zinloze services uit te schakelen, dus googlen ze op een aanpassingsgids en de meeste van die handleidingen zeggen dat Application Experience veilig kan worden uitgeschakeld.
Ik denk dat dit probleem moet worden gekoppeld aan het Windows 7-probleem en niet aan het VS-probleem en dat het beter zichtbaar moet zijn – het heeft lang geduurd voordat ik deze oplossing vond.
Nogmaals bedankt!
Antwoord 9, autoriteit 3%
Om nog een oplossing aan de lijst toe te voegen, wat ik heb gevonden is dat Visual Studio (2012 in mijn geval) af en toe bestanden vergrendelt onder verschillende processen.
Dus bij een crash kan devenv.exe nog steeds actief zijn en de bestanden vasthouden. Als alternatief (zoals ik net heb ontdekt), kunnen vstestrunner of vstestdiscovery het bestand ook vasthouden.
Sluit al die processen af en het probleem kan worden opgelost.
Antwoord 10, autoriteit 3%
Ik ben net hetzelfde probleem tegengekomen met VS2013, toen ik apparaatstuurprogramma’s maakte in C++ , en geen van de bovenstaande oplossingen leek het probleem op te lossen. Ik heb echter net ontdekt dat in mijn geval het probleem VMWare-gerelateerd lijkt te zijn.
Ik draaide een VMWare-werkstationclient met een gedeelde map gedefinieerd op de VM op mijn hele C:-schijf. Toen ik de gedeelde mappen op de VM-instellingen uitschakelde, kon VS2013 met plezier mijn .exe-bestanden bouwen.
Mijn nieuwe proces is:
1) Schakel de gedeelde map op de vm uit (VM-instellingen | Opties | Gedeelde mappen – en schakel het selectievakje uit)
2) Voer de build uit op de host-pc
3) Schakel de gedeelde map opnieuw in (en ga vanaf daar verder)
Hopelijk kan dit iemand anders helpen.
(BTW, de fouten die u ontvangt zijn dat de .exe (of andere bestanden) zijn vergrendeld of beheerdersrechten vereisen, maar dat is een rode haring – het lijkt mij dat de VMWare-share ervoor zorgt dat die bestanden als vergrendeld worden weergegeven .)
Antwoord 11, autoriteit 3%
Meestal betekent dit dat uw programma is vergrendeld en mogelijk niet wordt uitgeschakeld via taakbeheer of procesverkenner. Ik ontmoette een soortgelijk geval dat mijn programma een uitzondering had tijdens het uitvoeren en de Windows-foutrapportage activeerde waardoor het programma werd vergrendeld. In het geval dat Windows-foutrapportage het programma vergrendelt, kunt u naar Configuratiescherm->Systeem en Beveiliging->Actiecentrum->Probleemrapportage-instellingen gaan om “Nooit controleren op oplossingen” in te stellen.Hoop dat het helpt.
Antwoord 12, autoriteit 3%
Bij mij gebeurde het toen ik probeerde te bouwen in de debug-modus, maar het werkte prima in de release-modus. Ik heb de buildconfiguratie in de visuele studio gewijzigd van x86 in x64 en het werkte prima voor mij, aangezien ik op een 64-bits systeem draaide.
Antwoord 13
De fout komt (althans soms) van paden die te lang zijn. In mijn project doet het eenvoudigweg verminderen van het pad van het uitvoerbestand het werk:
“Eigenschappen/Configuratie-eigenschappen/Algemeen/Tussenliggende directory”
Het lijkt erop dat ik de padlimiet van 250 tekens heb bereikt.
Antwoord 14
Werken met Bjarne Stroustrup Programmeerprincipes en praktijk Met behulp van het C++ “FLTK”-voorbeeld kreeg ik dezelfde fout, maar na ongeveer 1 uur kreeg ik een idee, ik volgde een van de bibliotheken die al te zien waren in Projecteigenschappen -> Linker -> Invoer -> Aanvullende afhankelijkheden, in mijn geval volgde ik de kernel32.lib om te zien waar deze zich bevond en zag ik dat er veel kernel32.lib’s in verschillende mappen waren. Dus ik begon de FLTK-bibliotheken in die mappen te kopiëren en de laatste die ik probeerde werkte. Visual Studio 2013 Express vond de fltkd.lib en de code werkte.
In mijn geval was de juiste route C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
Ik weet niet hoe ik die route in Visual Studio moet instellen.
Ik weet niet zeker of die map Windows kits is gemaakt toen ik Microsoft Windows SDK voor Windows 7 en .NET Framework 4 (ISO) installeerde http://www.microsoft.com/en-us/download/details.aspx?id=8442
Ik hoop dat dit jullie helpt.
Antwoord 15
Ik had net hetzelfde probleem. Bij mij was de exe nog steeds actief, maar ik kon het niet beëindigen met Taakbeheer. Gewoon door VS opnieuw op te starten, werkte het voor mij.
Antwoord 16
De mijne is dat als je de MASM-lijstbestandsoptie een extra selectie instelt, je deze foutmelding krijgt.
Gebruik gewoon
Enable Assembler Generated Code Listing Yes/Sg
Assembled Code Listing $(ProjectName).lst
het is goed.
Maar eventuele extra’s die je hebt.