Derleme hatası: "Dosya başka bir işlem tarafından kullanıldığı için işlem dosyaya erişemiyor"

Bugüne webformskadar sadece yüzerek çalışan bir C # uygulamam var .

Şimdi bugün, aniden, uygulamayı her çalıştırmayı denediğimde, bir dosya kilitleme hatası alıyorum:

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

Hatayı araştırmak, bariz olanın ötesinde bir şey ortaya çıkarmaz, yani VS dosyanın kilitli olduğunu düşünüyor. Ve dosyayı kilitleyen kesinlikle Visual Studio'nun kendisidir, çünkü VS'yi kapatıp yeniden açtığımda, proje ilk seferinde iyi bir şekilde çalışır. İkinci kez çalıştırmayı denediğimde, dosya kilitleme hatası alıyorum.

VS'yi kapatmak ve uygulamayı her çalıştırmak istediğimde yeniden açmak uygun bir geçici çözüm değil! Dosyayı neyin kilitlediğini nasıl öğrenebilirim ve kilitlenmesini nasıl durdurabilirim?

DÜZENLEME: Bir başka ilginç keşif: Uygulamayı çalıştırmam bile gerekmiyor. Sadece bir kez derlemek dosya kilitlenmesine neden olur; Arka arkaya iki kez derleyemiyorum!

Bu problem benim çözümümdeki bir projeye özgü. Diğer tüm projeler iyi çalışıyor ve istediğim kadar gerçekleştirilebilir. Kendini kilitleyen sadece bu proje.

Benim için çalışan basit bir çözüm buldum. Bu böyle devam ediyor:

Sorun oluştuğunda, sadece üst kısımdaki yapı yapılandırmasını değiştirin ("Serbest Bırak" seçeneğinde "Hata Ayıkla" ya da tersi), oluşturun ve ardından önceki yapılandırmaya geri dönün ve yeniden oluşturun.

Yapılandırmayı değiştirmenin vcshost ve devenv'i serbest bırakacağını düşünüyorum.

Sorunu kendim çözdüm - yine de neden olduğuna dair hiçbir fikrim yok. Projeden tüm dosyaları kaldırarak, ardından yeniden ekleyerek ve bu şekilde sorunumun kaynağının hangi dosya olduğunu belirleyerek sorunu izole etmeye karar verdim. Böylece, dosyaları projeye tek tek yeniden ekledim, yolun her adımını derledim ve temizledim ... ta ki ...

... ve her şey hala iyi çalışıyordu.

Orijinal .csproj'umun kaynak denetimiyle bir karşılaştırma yaptım; gerçek fark yok. Ve .csproj'un önceki sürümüne geri dönmeyi denediğimde bile, yine de çalıştı.

Kara büyü. İşe yararsa, bazen neden diye sormamak daha iyidir - sadece kabul et ve devam et ...

DÜZENLEME: Sorun yinelenen bir sorundur ve form tasarımcısını derleme zamanında soyut / genel bir formun açtığı zamana izole ettiğime inanıyorum.

Alınan ders: Derlemeden önce herhangi bir soyut veya genel form veya denetimin Form Tasarımcısının kapalı olduğundan emin olun! Değilse, VS'yi kapatmanız ve yeniden açmanız gerekir!

Burada keşfettiğimiz şey şudur: Proje özellikleri sayfasındaki Hata Ayıkla sekmesinde, "Görsel stüdyo barındırma işlemini etkinleştir" seçeneğinin işaretini kaldırın. Bu özelliğin ne için olduğundan emin değilim, ancak bir kez kontrol edilmediğinde işi yapıyor.

Aslında "Visual Studio barındırma işlemini etkinleştir" seçeneğinin işaretli olmasını istemelisiniz. En azından VS2010 için zaten. Ayrıca bende:

"$ (TargetPath) .locked" del "$ (TargetPath) .locked" varsa "$ (TargetPath)" yoksa "$ (TargetPath) .locked" move "$ (TargetPath)" "$ (TargetPath) .kilitli"

önceden inşa seçeneklerinde. Bu sorun beni çok uzun zamandır zorladı ve John W. bu onay kutusundan söz edene kadar bunun var olduğunu ve düşük olduğunu ve zaten kontrol edilmediğini fark ettim bile.

Ayrıca -app-vshost.exe dosyasının hata ayıklama yapılmadığında bile arka planda çalıştığına dikkat edin. Her tahmin ettiğimde başarılı bir şekilde oluşturup çalıştırmasını sağlayan şey budur. Daha önce çalışmıyordu. Ayrıca hata ayıklama ve yayın klasörlerini temizlemeyi ve hedef türünü sürekli değiştirmeyi denedim ve yukarıda açıklananlar dışında hiçbir şey işe yaramadı. Daha önce benim çözümüm, derlemeler arasında sadece 5 dakika beklemekti, bu da çok sinir bozucu ve her şeyi yapmak için zaman alıcı hale geldi. Hangi sekmelerin nerede açıldığının veya XNA'ya karşı windows formunun veya tasarımcıların açıldığı önemli olan davranışta herhangi bir değişiklik görmedim. Bu sorun 32 bit veya 64 bit yapılarda meydana geldi ve bir uygulamayı ALT-F4 ile mi yoksa görev yöneticisiyle mi öldürdüğüm önemli değildi, bu teorik olarak uygulamanın kaynakları kapatmasına veya serbest bırakmasına izin vermiyordu. İlk başta bunun bir çöp toplama sorunu olduğunu düşündüm.

VS2017 - Windows görev yöneticisinde MSBuild.exe'nin tüm örneklerini kapatarak çözüldü

Anwer için biraz geç, ancak bunu projenin özellikleri> "Hata Ayıkla" sekmesine giderek> "Visual Studio barındırma işlemini etkinleştir" seçeneğinin işaretini kaldırarak çözüyorum.

Kilitli dosyayı yeniden adlandırarak (Windows Gezgini kullanarak) bu sorunun üstesinden geldim. Dosyayı silmeme izin verilmedi, ancak kilitli dosyayı yeniden adlandırmak işe yarıyor!

Bunu, bin \ Debug klasörünü silerek ve muhtemelen VS'yi yeniden başlatarak çözdüm.

Benim için, kurulmuş ve çalışan bir Windows Hizmetiydi. Onu durdurduğumda, yapı başarılı oldu.

Bu komutu Çalıştır kutusundan çalıştırın:

net stop iisadmin /y

ve sonra

iisreset

benim için çalıştı. 2003'e kıyasla

Son zamanlarda üzerinde çalıştığım bir çözüm oluşturmaya çalışırken bu sorunla karşılaştım (sadece bir winforms projesi değil). Başarısızlığa
ek olarak build, temizlik projelerinin sessizce başarısız olacağını fark ettim (bin klasörünü kontrol etmek dosyaların gerçekten silinmediğini gösterdi) ve Visual Studio'nun kapatılması devenvişlemi sonlandırmadı - bunun yerine çökmesine neden oldu. Windows kurtarma işlemi daha sonra Visual Studio'yu yeniden başlatır.

Bazı deneme yanılma işlemlerinden sonra, sorunların yalnızca VS'yi başlatırken "Son" menüsünden çözümü açtığımda başıma geldiğini gördüm.
Çözümü açmak, File >> Open >> Project/Solutiongenellikle olduğu gibi çalıştığını buldu.

Şu anda neden olduğuna dair hiçbir fikrim yok - buna bakmaya devam edeceğim ama şimdilik en azından çalışabilirim!

Sadece referansları kontrol edin ve projeye yapılan referansı kaldırın.

Açıklama: Sorunum, özel bir kontrol oluşturduktan ve tasarım formlarında kullanmak için araç kutusu paletine sürükleyip bıraktıktan sonra başladı. İlk olarak, özel kontrol kaynak dosyası (.cs) ile yürütülebilir projeler (.exe) arasında fazlalık olduğunu belirten bir uyarı görüntülendi. Yürütme / hata ayıklama sırasında hata ortaya çıktı: kullanıldığından (.exe) dosyasına erişilemedi (ve bu doğruydu).

Özel kontrolle ilgili tüm kaynak kodunu tam anlamıyla kaldırdım ve referansları kontrol edene ve eski özel kontrolü "alabilmek" için kendisine referans verene kadar sorun hala devam etti. Referansı kaldırdım ve bitirdim !!

Visual Studio'daki Xamarin uygulamamda da aynı sorunu yaşadım ve test mobil cihazımın fişini çekerek çözüldü. Uygulama kapatıldı ve hata ayıklayıcı durduruldu, ancak çözümü oluşturmaya veya yeniden oluşturmaya çalışırken hata hala devam ediyordu. Sadece cihazı fişten çıkardıktan sonra durdu çünkü bir çağrı almak zorunda kaldım.

Sadece 2 sentimi atmak için. Sorunum Görev Yöneticisi'ni açarak ve uygulamayı öldürerek çözüldü. Hiç çalıştığına dair herhangi bir gösterge olmadan arka planda çalışıyordu (görev çubuğunda hiçbir öğe yok, kullanıcı arabirimi yok, hiçbir şey yok), ancak bunun neden olduğundan emin değilim. Açıkçası, hata ayıklayıcı çalışmıyordu ve o sırada yalnızca tek bir VS örneği açılmıştı. Bunun VS 2017'de hala devam ediyor olması beni şaşırtıyor.

Belki de arka planı çalıştıran uygulamayı arayan ve yenisine başlamadan önce onu öldüren bir yapı adımı ekleyebilirim.

Aynı sorunu yaşadım ve önceki cevaplarda bahsedilen yöntemlerden herhangi birini kullanarak düzeltemedim. Görev yöneticisindeki tüm "SSIS Debug Hist (32 bit)" örneklerini öldürerek ve şimdi normal şekilde çalışarak sorunu çözdüm.

.NET projesinin Obj, perakende ve hata ayıklama klasörünü silmek ve yeniden oluşturmak benim için çalıştı.

Web uygulamanız nasıl yapılandırıldı? Cassini (tepsi web sunucusu) veya IIS altında mı çalışıyor?

Yine de bu normal bir şekilde olmamalı. Bence ProcessExplorer size bir işlemin hangi dosyaları kilitlediğini söyleyebilir. İşlem gezgini değilse diğer sysinternals araçlarından biri.

SI araçlarından birini indirmeden önce denenecek bir şey, Cassini web sunucusunu durdurmak ve bunun dosyayı serbest bırakıp bırakmadığını görmektir.

Benim için işe yarayan şey IIS'yi yeniden başlatmaktı

bende de aynı problem vardı. hata ayıklama / bırakma yapılandırmasını değiştirmek hile yapmadı. en azından arada bina olmadan.

benim çözümümde (winform), tasarımcıda winformun ana formunu açarak çözüldü. koda geçme (F7). Ardından kodu kapatın, winform tasarımcısını kapatın ve tümünü yeniden oluşturun (ctrl-shift-B). Bu benim için çalıştı.

Winform uygulamasından (bir arka plan çalışanı çalıştıran) bir tür tanıtıcı, kullanılan diğer kitaplıkların bazılarında hala bir dosya tanıtıcısına sahip gibi görünüyor.

Aynı çözümü iki Visual Studio örneği açtım.

Benim durumumda çalışan bazı vstest işlemleri vardı (çeşitli isimlerle ama hepsi vstest dizesini içeriyor). Bunları taskmgr'de sonlandırmak zorunda kaldım.

Aynı hata, Google Nuget destek paketlerini güncelleyerek çözüldü

Süreci bitirdiğimde .Net Core Hosther şey yolunda gitti. Visual Studio'yu kapatmam veya başka bir şeyi değiştirmem gerekmedi.

VS'de Docker ile geliştirme yapanlar için docker for windows servisini yeniden başlatın ve sorun anında çözülecektir.

Docker'ı yeniden başlatmadan önce, belirtilen tüm cevapları denedim, çalışan bir msbuild.exe işlemi bulamadım, ayrıca VS'yi boşuna yeniden başlatmayı denedim, sadece docker çalıştı.

Bir çözüm daha: dosyalar kilitlendiğinde, engelleme işlemi ("ServiceHub.Host.CLR.x64 (7764)" gibi) ve kimliği parantez içinde bildirilir. İşlemden kurtulmak için, PowerShell'i (x + Win + I) açın ve "Stop-Process -Id idNumber" yazın.

Yakın zamanda Service Fabric'e dağıtırken sorunla karşılaştım. Hata, bir 'dosyanın' kullanımda olduğunu ima ediyor, ancak bağlantı noktasının başka bir IDE tarafından kullanıldığını buldum. Halihazırda limanda barındırılan çalışan bir hizmeti durdurarak, bu istisnanın oluşmasını durdurabildim.

Ben de aynı sorunla karşılaşmıştım. Yukarıda listelenen Çeşitli Çözümleri denedim ama benim için işe yaramadı.

Bu sorunu Sunucu Gezgini'nden Bağlantıyı Kapatarak çözdüm ve Visual Studio'da açık olan tüm Sekmeleri kapattım.

Bu bir SSIS projesiyse, görev yöneticisini açın ve kilitli dosyaları serbest bırakması gereken tüm DtsDebugHost.exe örneklerini kapatın.

Visual Studio Code kullanıyorum ve bu hatayı dev sunucusu çalıştığı için aldım (dev sunucusunu tuşuna basarak çalıştırdım Ctrl + F5).

Böylece, durdurmak için sadece dur işaretine tıkladım ve hata ortadan kalktı.

Bu sorunu yaşadım (ve bu sadece VS'de değil başka yerlerde de gördüğüm bir sorun).

Dropbox'tan kaynaklanıyor (benim durumumda). Bazı kodları düzenledikten ve çalıştır'a bastıktan sonra, bazen dropbox dosyayı hemen kilitler (böylece onu işleyebilir).

Çözüm 1. Çalıştır'a tekrar basın

Çözüm 2. Dropbox'ı duraklatın. (dropbox'ı bulut yedeklemeniz olarak kullanıyorsanız iyi değildir)

Çözüm 3. Derleme klasörünü dropboxes eşitleme listesinden kaldırın.