Visual Studio “kopyalanamadı”… derleme sırasında

VS2012 C # projemin derlemesi sırasında bu hatayı almaya devam ediyorum

Error   41  Could not copy "obj\Debug\WeinGartner.WeinCad.exe" to
 "bin\Debug\WeinGartner.WeinCad.exe". 
 Exceeded retry count of 10. Failed.    


Error   42  Unable to copy file "obj\Debug\WeinGartner.WeinCad.exe" to
"bin\Debug\WeinGartner.WeinCad.exe". The process cannot access the file
'bin\Debug\WeinGartner.WeinCad.exe' because it is being used by another 
process.    

Şimdi süreci öldürdüğümü anladım

Weingartner.WeinCad.vhost.exe

çalışır (bazen) ama bu sinirleri bozuyor. Bunun olmasını durdurmak için herhangi bir yol var mı?

Hata ayıklayıcı ayarlarım

Visual Studio 2013'te benzer hata iletileri ile karşılaştım.

Çoğunlukla, bu durumun bir istisna nedeniyle bir hata ayıklama işlemi durdurulduğunda meydana geldiğini gördüm.

Clean + build bu sorunu benim için çözmediğinde, aşağıdakileri yaparak başarılı oldum:

• Visual Studio'yu kapatma
• binVe objklasörlerini silme ve
• Visual Studio yeniden açılıyor.

Bu "hata" Visual Studio 2003'ten beri var.

Son olarak, genellikle yürütülebilir dosyayı yeniden adlandırarak ve sonra silerek bu sorunun üstesinden gelebileceğimi buldum.

Visual Studio Premium 2013'te (Güncelleme 3), bunu önceden oluşturulmuş bir astarla çözdüm:

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

Bu, eski PDB dosyalarını (varsa) zarif bir şekilde siler, ardından bir .old.pdbuzantıyla kalan her şeyi yeniden adlandırır . Güzel bir yan etkisi, eski PDB hala kilitliyse, dosya adına başka bir .old parçası ekler ve Visual Studio'yu yeniden başlattığınızda ve bir derleme yaptığınızda bunların tümü temizlenir.

Örneğin, oturum / hata ayıklama oturumu 1 MyProject.pdbkilitli bırakır .
Bir daha inşa edişinizde:
MyProject.pdb->MyProject.old.pdb

Sonra oluşturma / ayıklama oturumu 2 başlatılır ve hem MyProject.pdb ve MyProject.old.pdbhala kilitli:
MyProject.old.pdb-> MyProject.old.old.pdb
MyProject.pdb->MyProject.old.pdb

Son olarak, Visual Studio'yu yeniden başlatmak ve yeni bir yapı oluşturmak her ikisinden de kurtulacak ve her zamanki gibi işleme devam edecektir.

Bunun nedeni başvurunuzu kapatmış olmanızdır, ancak yine de arka planda çalışmaktadır.

Geçici çözüm:

• Görev Yöneticisi'ne ( Ctrl+ Alt+ Esc) gidin.
• İşlemler sekmesine gidin ve "YourProjectName.exe" dosyasını bulun.
• İşleminizi bulamıyorsanız "Tüm kullanıcılardan işlemleri göster" i işaretleyin.
• Son İşlemi yapın.

Kalıcı çözüm: Kodlama ile başvurunuzu kapatmanız gerekir. İşte kod ...

System.Windows.Forms.Application.Exit();

Bu kodu tüm formdaki formun closing olayına koymanız gerekir. Misal:

private void frm_menu_FormClosing(object sender, FormClosingEventArgs e)
{
    System.Windows.Forms.Application.Exit();
}

.vhost.exe bir hata ayıklayıcı işlemidir, bu nedenle hata ayıklanan işlem düzgün bir şekilde kapanmamıştır. Muhtemelen onu canlı tutan bir hata var ve hata ayıklama işlemini doğru bir şekilde durdurmuyor - hata ayıklayıcıyı gerçekten öldürmek yerine 'hata ayıklamayı durdur' düğmesini tıklattığınızda, belki de bu kümeye sahipseniz, işlemden ayırma seçenekleri vardır.

Ama sorun bu - kopyalamaya çalıştığınız dosya işletim sistemi tarafından kilitleniyor (yani hala kullanılıyor), bu yüzden kopyalamayı önlüyor. Dosyanın boş olduğundan emin olun ve kopyalayabilirsiniz.

Görev yöneticisinde IISExpress'i öldürerek çözdüm

Antivirüsünüzü devre dışı bırakmalısınız (özellikle bir Avast ise) ve tekrar deneyin. Bana yardımcı oldu. Sorun, hata ayıklayıcı / oluşturucu VS tarafından yürütülmeden hemen önce Avast tarafından tehdit olarak tanımlanan .exe dosyası oluşturmak ve bunun için silinmiş olmasıdır.

Aşağıdaki inşa öncesi eylem sağlayarak (VS 2010) bu sorunu gidermek mümkün;

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

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

Alıntı:

Bunun çözümü,> projesinin Derleme öncesi olay komut satırı özelliğine yerleştirmektir (Derleme Etkinlikleri sekmesinde):

Kod Parçacığı

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

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

İstisna

Bazı durumlarda, bu özel durumla karşılaştığınız IISExpress'i çalıştırdığınızda (Build || Rebuild) Visual Studio'da :

"Obj \ Debug \ YourProjectName.dll" dosyası bin \ YourProjectName.dll "dosyasına kopyalanamıyor . İşlem 'bin \ YourProjectName.dll' dosyasına erişilemiyor çünkü başka bir işlem tarafından kullanılıyor

Çözüm

1. Oluşturulması gereken web projesine sağ tıklayın.
2. Özelliklere tıklayın.
3. Sol taraftaki Etkinlikler Sekmesini Oluştur'u seçin.
4. Derleme öncesi olayları komut satırında şu 2 satırı yapıştırın:

tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul
if errorlevel 1 taskkill /f /im "iisexpress.exe"

Sen iyi 2 GO!

Bir projenin derleme adını değiştirerek sorunu çözüyor gibi görünüyor.

Yani bunun yerine

Bunu buna değiştiriyorum

Sadece onu değiştiğini Bildirimi Increment and Recalliçin Increment_Recall, sadece boşluk kaldırıldı. Şimdi benim için iyi çalışıyor.

W3wp.exe (IIS) işlemini öldürmek genellikle bunu çözer.
Genellikle, bin klasörüne gidip silmeye çalışarak dosya üzerinde kilit olan işlemi öğrenebilirsiniz. Başka bir işlemin kullanılması durumunda, görüntülenecek hata iletisi, öldürülmesi gereken işlemin adını içerir.

Windows 8'de VS 2012 Sürüm 11.0.60610.01 Güncelleştirme 3'te aynı sorunla karşılaştım

Tasarımcı penceresi açık değildi ve proje basit bir konsol uygulamasıydı.

Dosyaya erişen vshost işleminin kaldırılması, işlem dosyaya erişmediği için çoğu zaman çalışmaz.

Çalışan ve en az zaman alan en basit çözüm, projeyi çözümden kaldırmak, çözümde başka bir proje oluşturmak ve ardından orijinali geri eklemektir.

Tahriş edici ve zaman kaybıdır, ancak bildiğim diğer tüm seçeneklerden en ucuzudur.

Bu yardımcı olur umarım...

Ben Break all processes when one process breakshata ayıklama seçenekleri (op ilk ekran görüntüsü -> ikinci seçenek) onay işareti kaldırarak çözdü düşünüyorum .
İşaretlemediğimden beri bir süredir iyi çalışıyor / çalışıyor.
Projemde MySql NET Connector ve DevExpress denetimlerini kullanıyorum. Bunlardan biri bu bayrak beeing aktive çünkü bağlantıları, ciltleri, vb iyi bertaraf değildi olabilir.

EDİTTİ: kesinlikle işe yarıyor! Artık 'Dosya kopyalanamıyor' ve Form tasarımcı hataları yok.

Ana proje taskkill / f / fi "pid gt 0" / im "YourProcess.vshost.exe" in derleme öncesi etkinliğini ekleyin

Benim 10 sent katkım.

Hala VS 2015 Güncelleme 2'de bu sorunu yaşıyorum.

Derleme hedefini değiştirmenin sorunu çözdüğünü buldum.

Şunu deneyin: DEBUG içinde iseniz RELEASE ve build'e geçin, sonra DEBUG'a geri dönün. Sorun gitti.

Stefano

Aşağıdaki adımları izleyin

1. Görev Yöneticisini Aç (Ctrl + Alt + Delete)
2. Performans sekmesi altında < ProjectNameOfYours.exe > öğesini seçin .
3. İşlemi Sonlandır'ı tıklayın.
4. Şimdi çözüm oluşturun.

Yukarıdaki adımlar hatayı kalıcı olarak çözdü :)

Yanıtların hiçbiri işe yaramazsa bu basit kontrolü deneyin. Projenizi EXE çalıştıran ve tutan herhangi bir MSbuild.exe bulun. MSBuild.exe'yi öldürün ve gitmek için iyi olmalısınız.

Bunun olmasını önlemek için bir çözüm veremem ama en azından kilitli dosyayı (windows explorer veya klasik komut penceresi) yeniden adlandırın ve derleyin / derleyin. VS201x'i yeniden başlatmanıza veya yeniden başlatmanıza gerek yoktur. Bazı deneyimlerle, eski dosyaları silmek veya yeniden adlandırmak için bir ön komut dosyası ekleyebilir ve bir kilit olması durumunda yoldan çıkabilirsiniz.

Bu diğer cevaba bakınız . Temel olarak, arka plan tüketen kaynak dosyalarında çalışan MSBuild.exe işlemleriniz olabilir. MSBuild'in komut satırı üzerinden başlatılmasına neden olan ön veya son oluşturma görevleriniz varsa, bu komuta "/ nr: false" bayrağını eklemeyi deneyin. Ancak yine, daha ayrıntılı bilgi için önceki cevaba bakınız.

Sonunda nasıl düzeltebilirim. İlk hata ayıklama exe hala çalışıyor çünkü neden ilk hata ayıklama sonra hata ayıklama devam edemiyor. Böylece, ilk hata ayıklamadan sonra, Görev Yöneticisi -> İşlem Sekmesi -> [proje adınız exe] 'e gidin.

benim için çalışıyor :)

@ Geoff'un ( https://stackoverflow.com/a/25251766/3739540 ) yanıtı iyidir, ancak yeniden derleme sırasında hata kodu 1'i atar.

İşte benim için işe yarayan (2> nul 1> nul sonunda + çıkış 0):

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb) 2>nul 1>nul
(if exist "$(TargetDir)*old.dll" del "$(TargetDir)*old.dll") & (if exist "$(TargetDir)*.dll" ren "$(TargetDir)*.dll" *.old.dll) 2>nul 1>nul
exit 0

T4 şablonlarında hata ayıklama yapıyorsanız, bu her zaman olur. Benim çözümüm (MS bunu düzeltmeden önce) sadece bu süreci öldürmek olacaktır:

Görev Yöneticisi -> Kullanıcı -> T4VSHostProcess.exe

Bu işlem yalnızca bir T4 şablonunda hata ayıkladığınızda ortaya çıkar, bir tane çalıştırdığınızda değil.

İşte kesinlikle bu sorundan kurtulmak için bir komut dosyası:

REM   This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM   The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM   This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM   delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM   assembly file (.exe / .dll) - .pdb file and eventually .xml file (documentation) are concerned
REM   use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

REM PreBuildEvent code
REM   $(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

REM References:
REM   http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
REM   http://stackoverflow.com/a/2738456/27194
REM   http://stackoverflow.com/a/35800302/27194

Komut dosyasının her bir VS projesi öncesi derleme olayından çağrılması gerekir.

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

1. Proje özelliklerini açma [menü> proje> özellikler]
2. "Hata ayıkla" sekmesini seçin
3. "Görsel stüdyo barındırma işlemini etkinleştir" seçeneğinin işaretini kaldırın
4. Hata ayıklamaya başla [F5]
5. Güvenlik uyarısı alacaksınız, sadece "tamam". Uygulamanın çalışmasına izin verir
6. Hata ayıklamayı durdurun.
7. Hata ayıklama sekmesi altında "Visual studio barındırma işlemini etkinleştir" seçeneğini işaretleyin,
8. Şimdi, hata ayıklamayı başlatmayı deneyin, tekrar hata görmeyeceksiniz

[Benim için çalış]

Bu soru, aşağıdaki hatayı ararken ilk sonuçtu:

"..." dosyası bulunamadığı için kopyalanamadı.

Visual Studio 2013'te (Güncelleme 3) oluştururken.

Çözüm: Visual Studio 2013'te "Verimlilik Elektrikli El Aletleri" nin kaldırılması.

https://connect.microsoft.com/VisualStudio/feedback/details/533411

Benim durumumda Resharper Unit Tests koşucusu (artı NUnit testleri, MsTests ile böyle bir sorun yaşamadım). Süreci öldürdükten sonra, OS veya VS2013'i yeniden başlatmadan işlemi yeniden başlatabildi

Hata ayıklayıcının hala bağlı olduğunu ve aynı Visual Studio örneğinde oluşturmaya çalıştığımı fark etmedim. Hata ayıklayıcıyı durdurduktan sonra inşa edebildim.

Vstest.executionengine.exe işlem (ler) i öldürmek bu sorunu benim için% 90 oranında çözmektedir. Bu işe yaramazsa, QTAgent32.exe dosyasını öldürmek ve sonra söz konusu proje için / bin ve / obj klasörlerini silmek de işe yarar .

Bu, iş günümün en rahatsız edici kısmı. :)

Benim için Visual Studio'nun dosya yazma / okuma / yürütmesine izin vermeyecek Avast antivirüs oldu. Bu yüzden antivirüs hariç tutma listesine Visual studio 2010/2012 klasörünü eklemek zorunda kaldım. Ve o baamdan hemen sonra ... işe yarıyor.

Tüm wcfSvcHost örneklerini kapattığınızdan emin olun ve tekrar deneyin. Benim için çalıştı!