Hata: Başka bir işlem tarafından kullanıldığından bin / Hata Ayıklama /… dosyasına erişilemiyor

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

"Obj \ Debug \ My Dream.exe" dosyası "bin \ Debug \ My Dream.exe" klasörüne kopyalanamıyor. İşlem, başka biri tarafından kullanıldığından 'bin \ Debug \ My Dream.exe' dosyasına erişemiyor. işlemek."

İşlem Gezgini'ni kullanarak, MyApplication.exe'nin devre dışı olduğunu görüyorum, ancak daha önce hata ayıklamayı durdurduğum halde Sistem işlemi hala kullanıyor. Kodumu ne zaman değiştirsem ve hata ayıklamaya başladığımda bu gerçekleşecek. Projeyi USB'ye kopyalarsam ve hata ayıklarsam, tamam çalışıyor.

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

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

Ugh, bu eski bir sorun, arada bir Visual Studio'da ortaya çıkan bir şey. Beni birkaç kez ısırdı ve VS ile yeniden başlamak ve savaşmak için saatlerimi kaybettim. Eminim burada SO'da birden fazla tartışılmıştır. Ayrıca MSDN forumlarında da konuşuldu. Gerçek bir çözüm yok, ancak birkaç geçici çözüm var. Araştırmaya buradan başlayın .

Olan şey, VS'nin bir dosya için bir kilit alması ve ardından onu serbest bırakmamasıdır. İronik olarak, bu kilit VS'nin dosyayı silmesini engeller, böylece uygulamayı yeniden oluşturduğunuzda dosyayı yeniden oluşturabilir. Görünen tek çözüm VS'yi kapatıp yeniden başlatmaktır, böylece dosya üzerindeki kilidi serbest bırakır.

Özgün çözümüm, bin / Debug klasörünü açmak ve yürütülebilir dosyayı yeniden adlandırmaktı. Sen olamaz silmek kilitli eğer, ama bunu adlandırabilirsiniz. Böylece, sonuna bir sayı veya başka bir şey ekleyebilirsiniz; bu, tüm pencerelerinizi kapatmanıza ve VS'nin yeniden başlamasını beklemenize gerek kalmadan çalışmaya devam etmenize olanak tanır. Hatta bazı insanlar , eski çıktı dosya adının sonuna rastgele bir dize eklemek için bir ön oluşturma olayını kullanarak bunu otomatik hale getirdiler. Evet, bu bir dev hack, ancak bu sorun o kadar sinir bozucu ve zayıflatıcı oluyor ki her şeyi yapacaksınız.

Biraz daha deney yaptıktan sonra, sorunun yalnızca tasarımcılardan biri açıkken projeyi inşa ettiğinizde ortaya çıktığını öğrendim. Bu yüzden, benim için uzun vadede işe yarayan ve bu aptalca hatalardan biriyle tekrar uğraşmamı engelleyen çözüm, bir WinForms projesi oluşturmadan önce tüm tasarımcı pencerelerini her zaman kapatmamı sağlamaktır. Evet, bu da biraz rahatsız edici, ancak VS'yi saatte iki kez veya daha fazla yeniden başlatmak zorunda kalmaktan kesinlikle daha iyi.

Bunun WPF için de geçerli olduğunu varsayıyorum, ancak kullanmıyorum ve kişisel olarak orada sorun yaşamadım.

Ayrıca henüz VS 2012 RC'de yeniden üretmeyi denemedim. Henüz orada tamir edilip edilmediğini bilmiyorum. Ancak şimdiye kadarki deneyimim, Microsoft'un düzeltdiğini iddia etmesine rağmen hala açılmayı başardığı oldu. Hala VS 2010 SP1'de var. Elbette programcılarının ne yaptıklarını bilmeyen aptallar olduğunu söylemiyorum. Hatanın birden fazla nedeni olduğunu ve / veya laboratuvarda güvenilir bir şekilde yeniden üretmenin çok zor olduğunu düşünüyorum. Bu, kişisel olarak herhangi bir hata raporu göndermemiş olmamla aynı nedenden ötürü (diğer insanları + 1'lemiş olmama rağmen), çünkü Abominable Snowman gibi, güvenilir bir şekilde yeniden üretemiyorum.

_{<özellikle kimseye yönelik olmayan son rant>}

Bu hatayı daha önce, Visual Studio 2008'de bile yaşadım. Geri geldi ve Visual Studio 2012'de daha yaygın.

İş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"

Bilgisayar (sağ tıklama) -> yönet -> Hizmet ve Uygulama -> hizmet -> Uygulama deneyimini etkinleştir

Benim için çalıştı!

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 oluşturarak sorunu çözebildim.

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

En azından benim durumumda, visual studio 2012'nin, oluşturulduktan sonra yok olmayan en az iki msbuild.exe hayalet işlemi oluşturduğunu fark ettim. Bu zombiler görünüşe göre dosya kilitlerinin ortaya çıkmasına neden oluyor.

Msbuild.exe'nin öldürülmesi tek seferlik çözümdür, her derleme için yapılması gerekir.

Ama sonra paralel oluşturmayı bir kez ve herkes için devre dışı bırakabileceğimi anladım - Araçlar> Seçenekler> Projeler ve Çözümler> Oluştur ve Çalıştır> "maksimum paralel proje derlemesi sayısı" na gittim - varsayılan olarak 8 değerindedir, I 1'e geçtim. Cazibe gibi çalışıyor.

Elbette derlemeler şimdi biraz daha yavaş, ancak üzgün olmaktan daha güvenli. En azından bu küçük proje için birden fazla derleme iş parçacığına ihtiyacım yoktu.

Bunun eski bir soru olduğunu anlıyorum. Maalesef, .net core 2.0başvurumda aynı sorunla karşılaşıyordum visual studio 2017. Bu yüzden benim için çalışan çözümü paylaşmayı düşündüm. Bu çözümden önce aşağıdaki adımları denedim.

1. Görsel stüdyo yeniden başlatıldı
2. Tüm uygulamayı kapattı
3. Çözümümü temizle ve yeniden inşa et

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

Sonra açtım Task Managerve seçtiğim dotnetişlemi ve ardından Görevi sonlandır düğmesine tıkladım. Daha sonra Visual Studio'mu açtım ve her şey yolunda gidiyordu.

Birim testlerini çalıştırırken bu sorunu yaşıyorsanız cevabımı burada görün . Cevap aşağıda kopyalandı:

Sébastien'in cevabına dayanarak, vstest.*hala çalışmakta olan yürütülebilir dosyaları otomatik olarak öldürmek için test projeme bir ön oluşturma adımı ekledim . Aşağıdaki yapım öncesi komut benim için çalıştı:

taskkill /f /im vstest.*
exit 0

exit 0Komut hiçbir varken inşa başarısızlığını önlemek için sonundadır vstest.*çalışan yürütülebilir.

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

Bunu düzeltmek için öncelikle hala onu kullanan uygulamayı anlamanız gerekir. "MSBuild" ve "MSBuild host" gibi tüm işlemleri kapattım. Ancak bu yeterli değil. "Kod Sözleşmelerini" yüklediyseniz ve etkinleştirdiyseniz, bazen bu işlemi kontrol etmek ve kapatmak için DLL dosyalarınızı alır.

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

Son olarak, işlemin DLL dosyanızı kullandığını anlamak için Dosya Yöneticinizdeki "obj" klasörünü silmeyi deneyebilirsiniz ve bu işlem başarısız olur, asılı işlemin açıklamasını içeren "Mesaj Penceresi" ni görebilirsiniz. Ayrıca varyant olarak "Sys Internals Suite" uygulamasını kullanmayı deneyebilirsiniz.

Benim için çalıştı. Görev Yöneticisi -> Proje adı -> Görevi sonlandır. (proje ismimle aynı 3 işlemim oldu);

VS 2013; 8 kazanın;

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

Visual Studio 2017'de bu sorundan rahatsız oldum. Yaklaşık iki veya üç hafta önce başladı ve üretkenliğimi ciddi şekilde tüketti. Clean ve Rebulid çalışmadı; Makinemi yeniden başlatmak bile işi yapmıyor.

Sorunla başa çıkmanın bir yolu, sorun teşkil eden montajı temizlemek ve hemen ardından çalıştırmak istediğiniz projeyi (yeniden oluşturmanın aksine) oluşturmaktır. Bu, zamanın yaklaşık% 30'unda çalışır.

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

Benim durumumda "Tüm Dosyaları Göster" seçeneğini etkinleştirmiştim. Visual Studio 2017

Çalıştır taskmanager.
Bulun netcoreve silin.
Daha sonra dosyayı manuel olarak veya çalıştırarak silebilirsiniz Clean.

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 önlemleri arasında bir etkileşim olduğundan şüphelenmek için geldim.

Biraz oynadıktan sonra, antivirüsümü değiştirdiğimde kaybolmuş olabilir , böylece

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

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

Görünüşe göre yapı aslında önce DLL'yi buraya yazıyor, sonra onu son derleme konumuna kopyalıyor.

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

Formları kapatmadan veya VisualStudio'yu yeniden başlatmadan en hızlı yolu buldum, projenin derleme sayfasına gidip "Gelişmiş Derleme Seçenekleri ..." düğmesine tıklayın. Ardından seçeneklerden birinde herhangi bir değişiklik yapın (örneğin, Hata Ayıklama Bilgilerini Oluştur'u Tam'dan yalnızca pdb'ye değiştirin) ve ardından Tamam'a tıklayın. Her seferinde çalışır ve MS bu hatayı düzeltene kadar yapmak zorunda kalacak (VS2012'den VS2013'e geçene kadar bu sorunu hiç yaşamadım)

Başka bir not, projeyi veya çözümü temizleyemezseniz, oluşturulmayacaktır. Dosyalar kesinlikle VS tarafından kilitlendi (bir antivirüs sorunu değil, en azından benim durumumda değil)

Tüm bu önerileri ve başka yerlerde bulunan diğer önerileri denedim ve benim için işe yarayan tek şey bilgisayarımı yeniden başlatmaktı. Sonra temiz bir çözüm yaptım ve ardından yeniden inşa ettim. Referans için Visual Studio 2013 kullanıyorum.

Aynı sorunla karşılaştım ve bulduğum şey aslında arka planda birden fazla Windows form uygulaması çalıştırıyor . Başvurunuzun iki formu olduğunda ve ana formunuz olmayan 2. formu kapattığınızda , başvurudan tamamen çıkılmaması durumunda gerçekleşir.

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

• exe aracılığıyla veya
• hata ayıklamadan çalıştır

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

Ön derleme komutu

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

Yardım etti

[Çözüldü] Hata: Bin / Hata Ayıklama /… dosyasına erişilemiyor çünkü başka bir işlem tarafından kullanılıyor:

Bu hatayı, ilk önce bir form yükleme, ardından bazen otomatik olarak kaybolacak ve ekrana yüklenen ikinci form gibi arka arkaya iki pencere çalıştırmaya çalışırken alıyorsunuz.

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

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

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

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

Basit bir çözüm, bin \ Debug klasörüne gitmeniz, bu klasördeki tüm dosyaları silip yeniden oluşturmanızdır. Çalışmazsa, Visual Studio'yu kapatın ve ardından dosya gezgini kullanarak bin \ Debug klasörüne gidin, sol tarafta Dosya> Komut İstemi Aç> Komut İstemi'ni Yönetici Olarak Aç> Bu komutu girin "DEL / F / Q / A * "> ardından yeniden oluşturun

Cody Gray'in cevabını kısmen yararlı buldum, çünkü beni bazılarınızın da deneyimlemiş olabileceği problemimin gerçek kaynağına yönlendirdi: visual studio'nun test yürütmesi varsayılan olarak açık kalıyor ve dosyalar üzerinde bir kilit sağlıyor.

Çoğunlukla yararsız olan bu davranışı durdurmak için https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 adresindeki talimatları izleyin. -50.727-1-rtmrel

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

Benim sorunum dotnet'in kapatılmasıydı ve VS ne zaman yeni bir dll oluşturmaya çalışsa veya eski bir dll'ye erişmeye çalışsa, dotnet işlemi dll'ye kilitlenecek ve görsel stüdyonun dll'yi klonlamasını durduracaktı. Çözüm, sadece görev yöneticisindeki tüm dotnet görevlerini sonlandırmaktır (eğer birini sonlandırmaya çalışıyorsanız ve kapanmayacaksa, sadece ölü olanı kaldıracaktır, bu çalıştığı anlamına gelir).

VisualStudio'yu kapatın, ctrl-alt-delete, Görev Yöneticisi'ni seçin, tüm MSBuild işlemlerini bulun ve 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ıklama / bin'deki .pdb dosyasında bir kilit tuttuğu oldukça ciddi bir hataya sahiptir. Klasör. Tüm MSBuild (hata ayıklayıcı) işlemlerini bitirdikten sonra, / debug / bin klasörünü silin ve çözümünüzü Visual Studio'da yeniden açın. Şimdi gitmekte iyisin. Microsoft'un bu saçmalığı düzeltmesi gerekiyor.

Bir güncellemeden sonra benzer bir davranışa sahip olan VS 2017 ile ilgili ayrı bir soru açtım . Sorun, virüsten koruma 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.

Bu sorunu çözdüm ..

hata ayıklamanın yakınında bazı yapılandırmalarla açılır menüyü görürsünüz. Varsayılan olarak Herhangi bir CPU vardı. X86'yı seçin ve çalışacağı programı çalıştırın. X86 yoksa, yapılandırma yöneticisine gidin ve x86'yı ekleyin

Başka bir kludge, ugh, ama çok kolay ve VS 2013'te benim için çalışıyor. Projeye tıklayın. Özellikler panelinde bir değer içeren Proje Dosyası adlı bir giriş olmalıdır.

(proje adınız) .vbproj

Sonuna bir -01 eklemek gibi proje adını değiştirin. Kilitli olan orijinal .zip dosyası hala oradadır, ancak artık başvurulmamaktadır ... bu nedenle çalışmanız devam edebilir. Bilgisayar bir sonraki yeniden başlatıldığında, bu kilit kaybolur ve hatalı dosyayı silebilirsiniz.