web-gelistirme-sc.com

Hata: bin / Debug / ... dosyasına erişilemiyor çünkü başka bir işlem tarafından kullanılıyor.

Projemde hata ayıkladığımda aşağıdaki hatayı alıyorum:

"Obj\Debug\My Dream.exe" dosyası "bin\Debug\My Dream.exe" dizinine kopyalanamıyor. Başka bir kişi tarafından kullanıldığı için işlem 'bin\Debug\My Dream.exe' dosyasına erişemiyor. süreci."

İşlem Gezgini'ni kullanarak, MyApplication.exe'nin çıktığını görüyorum, ancak daha önce hata ayıklamayı durdurmama rağmen Sistem işlemi hala kullanıyor. Ne zaman kodumu değiştirip hata ayıklamaya başladığımda bu olacak. Projeyi USB'ye kopyalayıp hata ayıklamıyorsam, Tamam çalışıyor.

Neden? Bu hatayı nasıl düzeltebilirim?

Window 7 Professional'ı kullanıyorum. Xp ile bu hatayı hiç almadım.

104
Trần Minh

Bu eski bir sorundur, arada bir de Visual Studio'da ortaya çıkan bir şey. Bana birkaç kez ısırıldı ve yeniden başlayıp VS ile savaşarak saatlerimi kaybettim. Eminim burada bir kereden fazla SO konuşuldu. Ayrıca MSDN forumlarında da konuşuldu. Gerçek bir çözüm yok, ancak birkaç geçici çözüm var. Burada araştırmaya başlayın .

Olan şu ki, VS bir dosya üzerinde bir kilit alıyor ve ardından bırakmıyor. İronik olarak, bu kilit, uygulamayı yeniden oluşturduğunuzda yeniden oluşturabilmesi için VS'nin dosyayı silmesini önler. Görünen tek çözüm, dosyadaki kilidi serbest bırakması için VS'yi kapatıp yeniden başlatmaktır.

Orijinal geçici çözümüm, bin/Debug klasörünü açmak ve yürütülebilir dosyayı yeniden adlandırmaktı. Kilitliyse silemezsiniz , ancak yeniden adlandırabilirsiniz. Böylece, sonuna kadar bir sayı ekleyebilir veya bir şey ekleyebilirsiniz; bu, tüm pencereleri kapatıp VS'nin yeniden başlatılmasını beklemeden çalışmaya devam etmenizi sağlar. Bazı insanlar bunu bir derleme öncesi olayı kullanarak otomatik hale getirdiler eski çıktı dosya adının sonuna rasgele bir dize eklemek için. Evet, bu bir dev kesmektir, ancak bu sorun çok fazla sinir bozucu olur ve her şeyi yapmanıza yol açmaz.

Daha sonra, biraz daha denemeden sonra, sorunun projeyi tasarımcılardan biri açıkken kurduğunuzda ortaya çıktığını öğrendim. Bu yüzden, uzun süredir benim için çalışan ve bir kez daha bu saçma hatalardan biriyle uğraşmamı engelleyen çözüm, bir WinForms projesi inşa etmeden önce tüm tasarımcı pencerelerini daima kapattığımdan emin olmak. Evet, bu da biraz sakıncalıdır, ancak kesinlikle VS'yi bir veya iki kez yeniden başlatmak zorunda kalmadan pantolonu atıyor.

Bunun WPF için de geçerli olduğunu varsayıyorum, ancak kullanmam ve sorunu kişisel olarak yaşamamış olmama rağmen.

Ayrıca VS 2012 RC'de çoğaltmayı henüz denemedim. Henüz orada tamir edilip edilmediğini bilmiyorum. Ancak şu ana kadarki deneyimim, Microsoft tarafından düzeltildiğini iddia ettikten sonra bile hala ortaya çıkmayı başardığı yönünde oldu. Hala VS 2010 SP1'de var. Programcılarının ne yaptıklarını bilmeyen salaklar demiyorum elbette. Böceğin sadece birkaç nedeni var ve/veya laboratuarda güvenilir şekilde çoğaltılmasının çok zor olduğunu düşünüyorum. Bu, kişisel olarak hata raporları sunmamamın aynı nedeni (diğer insanları + 1'yapmış olmama rağmen), çünkü Abominable Snowman gibi güvenilir bir şekilde yeniden üretemiyorum.

<özellikle kimseye yönlendirilmeyen uç rant>

112
Cody Gray

Visual Studio 2008'de bile bu hatayı daha önce üzerimden kaybettim. Visual Studio 2012'de daha da yaygınlaştı.

İşte yaptığım şey.

Bunu zahmetli projenin yapım öncesi etkinliğine yapıştırın:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
59
ScottN

Bilgisayar (sağ tıkla) -> yönet -> Servis ve Uygulama -> servis -> Uygulama deneyimini etkinleştir

Benim için çalıştı!

21
Alex

Visual Studio 2013'te de aynı sorunu yaşadım. Projem için buna neyin sebep olduğundan emin değilim, ancak çözümü temizleyerek ve yeniden kurarak bunu düzeltebildim.

  1. Yap> Temiz Çözüm
  2. Yap> Çözümü Yeniden Oluştur
13
lkisac

En azından benim durumumda, görsel stüdyo 2012'nin en az iki msbuild.exe hayalet işlemi oluşturduğunu farkettim, bu da derlemeden sonra yok olmadı. Bu zombiler görünüşe göre dosya kilitlerinin görünmesine neden oluyor.

Msbuild.exe 'nin öldürülmesi tek seferlik bir çözümdür, derleme bazında yapılması gerekir.

Ama sonra paralel yapıyı bir kez ve herkes için devre dışı bırakabileceğimi öğrendim - Araçlar> Seçenekler> Projeler ve Çözümler> Yapı ve Çalıştır> “maksimum paralel proje derlemesi sayısı” na - varsayılan olarak 8 değerine sahip, 1'e geçti. Cazibe gibi çalışır.

Tabii ki, şimdi inşa biraz daha yavaş, ama üzgünüm daha güvenli. En azından bu küçük proje için birden fazla yapım dizisine ihtiyacım yoktu.

7
TarmoPikaro

Bunun eski bir soru olduğunu biliyorum. Maalesef, .net core 2.0 içindeki visual studio 2017 başvurumla aynı sorunla karşı karşıyaydım. Bu yüzden, benim için işe yarayan çözümü paylaşmayı düşündüm. Bu çözümden önce aşağıdaki adımları denemiştim.

  1. Yeniden başlatılan görsel stüdyo
  2. Tüm başvuru kapatıldı
  3. Çözümümü temizle ve yeniden oluştur

Yukarıdaki adımların hiçbiri sorunu çözmedi.

Sonra Task Manager'imi açtım ve dotnet işlemini seçip Bitir görev düğmesine tıkladım. Daha sonra Visual Studio'yu açtım ve her şey iyi çalışıyordu.

enter image description here

2
Sibeesh Venu

Ünite testleri yaparken bu sorunu yaşıyorsanız cevabımı burada görün. Cevap aşağıda kopyalandı:

Sébastien'in cevabına dayanarak, halen devam eden vstest.* çalıştırılabilir dosyasını otomatik olarak öldürmek için test projeme bir ön yapım adımı ekledim. Aşağıdaki derleme öncesi komut benim için çalıştı:

taskkill /f /im vstest.*
exit 0

exit 0 komutu, çalışan hiçbir vstest.* çalıştırılmaz olduğunda derleme arızasını önlemek için sondadır.

2
mrtumnus

Uygulamanın önceki herhangi bir çalışmasının (örneğin, hata ayıklama seçeneği olmadan başlama) gerçekten durdurulduğundan emin olun. Bir WPF uygulaması üzerinde çalışıyordum, hata ayıklamadan başladım ve hatayı almaya devam ettiğimde minimize ettim. Uygulamanın kapanmasından sonra VS davranışı normale döndü.

1
sk1900

Benim için çalıştı. Görev Yöneticisi -> Projenin adı -> Görevi sonlandır. (benim proje adım ile aynı 3 işlem vardı);

VS 2013; 8 kazan;

1
GroD

Son zamanlarda Visual Studio 2012 ile aynı hata açıklamasıyla ilgili bir sorun yaşıyorum: "İşlem dosyaya erişemiyor çünkü başka bir işlem tarafından kullanılıyor ..."

Öncelikle bunu düzeltmek için hala kullanan uygulamayı anlamanız gerekir. "MSBuild" ve "MSBuild Host" gibi tüm işlemleri kapattım. Ancak bu yeterli değil. Eğer "Kod Sözleşmeleri" ni kurduysanız ve açmışsanız, bazen bu işlemi kontrol etmek ve kapatmak için DLL'lerinizi alır.

Yani, "CCCheck.exe" nin tüm işlemlerini durdurmanız gerekir ve hepsi bu.

Son olarak, işlemin DLL yöntemini kullandığını anlamak için her zaman Dosya Yöneticinizdeki "obj" klasörünü silmeyi deneyebilirsiniz ve bu işlem başarısız olur, asılı kalmayı açıklayan "Mesaj Penceresi" ni görebilirsiniz operasyon. Ayrıca, bir değişken olarak "Sys Internals Suite" uygulamasını kullanmayı deneyebilirsiniz.

1
Yarkov Anton

Benim durumumda "Tüm Dosyaları Göster" i etkinleştirdim. Visual Studio 2017

1
JD - DC TECH

Visual Studio 2017'de bu sorundan rahatsız oldum. İki ya da üç hafta önce başladı ve verimliliğimi ciddi bir şekilde yedi. Temiz ve Rebulid işe yaramadı; Makinemi yeniden başlatmak bile iş yapmıyor.

Bu sorunla başa çıkmanın bir yolu, rahatsız edici Meclisi temizlemek ve hemen sonra çalıştırmak istediğiniz projeyi (yeniden inşa etmenin aksine) inşa etmektir. Bu, zamanın yaklaşık% 30'unu oluşturur.

Ancak, muhtemelen bulduğum en güvenilir çözüm bir Geliştirici Komut İstemi açmak ve doğrudan msbuild kullanmaktır. Bunu son üç gündür yapıyorum ve şimdiye kadar sorun bir kez olmadı.

1
Rob Lyndon

taskmanager komutunu çalıştırın.
netcore öğesini bulun ve silin.
Ardından dosyayı manuel olarak veya Clean çalıştırarak silebilirsiniz.

0
BobSpring

cody Gray'in cevabını kısmen faydalı buldum, bu da beni, bazılarınızın da yaşayabileceği benim problemimin asıl kaynağına yönlendirdi: Visual Studio'nun deneme uygulaması varsayılan olarak açık kalıyor ve dosyalar üzerinde bir kilitlenme sağlıyor.

Bu ağırlıklı olarak işe yaramaz davranışı durdurmak için https://connect.Microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012) 'daki talimatları uygulayın. -11-0-50727-1-rtmrel

Test menüsü -> Test Ayarları -> "Test Yürütme Motorunu Çalışmaya Devam Et" seçeneğinin işaretini kaldırın

0
neogeek

[Çözüldü] Hata: Başka bir işlem tarafından kullanıldığı için bin/Debug /… dosyasına erişilemiyor:

Bu hatayı ilk formu doldurmak gibi birbiri ardına iki pencereyi çalıştırmaya çalışırken, bazen otomatik olarak kaybolacak ve ikinci formu ekrana yükleyeceğiniz zaman bu hatayı alıyorum.

Temel olarak, arka planda çalışan ilk formunuzu ve bu hatanın arkasındaki ana nedeni kapatmanız gerekir.

İlk formu kapatmak için ikinci form load olay işleyicisine bu iki kod satırını eklemeniz gerekir.

    Form1 form = new Form1();
    form.Close();

Bu hatayı mükemmel şekilde çözecektir.

0
Sabir Al Fateh

Formları kapatmadan veya VisualStudio'yu yeniden başlatmadan en hızlı yolu buldum projenin derleme sayfasına gidip "Gelişmiş Derleme Seçenekleri ..." düğmesini tıklayın. Ardından seçeneklerden birinde herhangi bir değişiklik yapın (diyelim ki, Hata Ayıklama Bilgisini Üret seçeneğinin Yalnızca tam olarak pdb olarak değiştirilmesi), ardından Tamam'ı tıklayın. Her zaman çalışır ve MS bu hatayı düzeltene kadar yapmak zorunda kalır (VS2012'den VS2013'e geçene kadar bu problemi yaşamamıştım)

Başka bir not, projeyi veya çözümü temizleyemezseniz inşa etmez. Dosyalar kesinlikle VS tarafından kilitlendi (bir virüsten koruma sorunu değil, en azından benim durumumda değil)

0
MC9000

VisualStudio'yu kapatın, ctrl-alt-delete, Görev Yöneticisi'ni seçin, tüm MSBuild işlemlerini bulup sonlandırın - VisualStudio temelde hata ayıklayıcısının kontrolünü kaybettiği ve hata ayıklayıcının hata ayıklayıcı/bölme .pdb dosyasında bir kilit tuttuğu oldukça ciddi bir hataya sahip Klasör. Tüm MSBuild (debugger) işlemlerini bitirdikten sonra,/debug/bin klasörünü silin ve çözümünüzü Visual Studio'da yeniden açın. Şimdi gitmen iyi. Microsoft'un bu sorunu çözmesi gerekiyor.

0
JakeJ

Çok geç olabilir. Ancak benzer bir sorunla karşılaştım ve benim durumumda projenin kendine referansı vardı. Bu nedenle, Referanslardan silmek bir çekicilik gibi çalıştı !!!

0
aby

Basit bir çözüm, bin\Debug klasörüne gidip o klasördeki tüm dosyaları silmeniz ve sonra yeniden kurmanızdır. Çalışmazsa, Visual Studio'yu kapatın, ardından Explorer dosyasını kullanarak bin\Debug klasörüne gidin, soldaki dosyada, Dosya> Komut İstemi Aç> Komut İstemi Yönetici Olarak Aç> Bu komutu gir "DEL/F/Q/A * "> ardından yeniden oluştur

0
Hung Vu

Önceden derleme komutu

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

Yardım etti

0
Kakha Middle Or

Bu saf bir spekülasyon ve bir cevap değil.

Ancak bir süredir bu sorunu yaşıyorum.

Bir süre sonra VS ile AV önlemlerim arasındaki etkileşimden şüphelenmek için geldim.

Biraz çaldıktan sonra, antivirüsümü değiştirdiğimde belki de ortadan kaybolmuş gibi görünüyor.

C:\Users [adı]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

klasör, gerçek zamanlı korumaya dahil edilmedi.

Derleme aslında burada ilk önce DLL yazıyor, ardından son derleme konumuna kopyalıyormuş gibi görünüyor.

0
PolicyWatcher

Benim sorunum dotnet'in kapatılmasıydı ve VS ne zaman yeni bir dll oluşturmaya çalışsa ya da eski bir tanesine erişirse, dotnet işlemi dll üzerine kilitlenir ve görsel stüdyosunun dll'yi klonlamasını durdururdu. Çözüm, görev yöneticisindeki tüm dotnet görevlerini sonlandırmaktır (bir işi bitirmeye çalışıyorsanız ve kapanmazsa, bu işe yaradığı anlamına gelirse, yalnızca ölü olanı kaldıracaktır).

0
Joel Hines

Tüm bu önerilerin yanı sıra başka bir yerde bulunan diğer önerileri denedim ve benim için çalışan tek şey bilgisayarımı yeniden başlatmaktı. Sonra temiz bir çözüm yaptım, ardından yeniden inşa ettim. Başvuru için Visual Studio 2013 kullanıyorum.

0
mortey

Bu aynı konuyu çalıştırdım ve bulduğum şey aslında gerçekte arka planda çalışan mulitple Windows form uygulamasını çalıştırıyor. Uygulamanızın iki formu olduğunda ve 2. formu kapattığınızda ana formu kapatırsınız, böylece uygulama tamamen çıkıldı.

Genelde uygulamamı çalıştırırım

  • onun exe aracılığıyla veya
  • hata ayıklama olmadan çalıştırmak

Çözüm, Windows form uygulamasının diğer örneğine yakın . Bu one uygulama örneğinizi her zaman kapatmanın bir yoludur.

0
jmvtrinidad

Bir güncelleme sonrasında benzer davranış gösteren VS 2017 ile ilgili ayrı bir sor açtım. Sorun antivirüs programı tarafından oluşturulmuş gibi görünüyordu.

Bin klasörünü antivirüs dışlama listesine ekledim, makineyi yeniden başlattım ve şimdi çalışıyor gibi görünüyor.

0
meJustAndrew