Visual Studio derlemesi başarısız: exe dosyası obj \ debug'dan bin \ debug dosyasına kopyalanamıyor


193

Güncelleştirme: Bu hatayı yeniden üreten örnek bir proje burada Microsoft Connect'te bulunabilir . Ayrıca , aşağıdaki kabul edilen cevapta verilen çözümün bu örnek proje üzerinde çalıştığını test ettim ve doğruladım . Bu çözüm sizin için işe yaramıyorsa, muhtemelen farklı bir sorun yaşıyorsunuz (ayrı bir soruya aittir).


Bu daha önce sorulan bir soru, hem burada Stack Overflow'da hem de diğer yerlerde, ama şimdiye kadar bulduğum önerilerin hiçbiri bana yardımcı olmadı, bu yüzden yeni bir soru sormaya çalışmalıyım.

Senaryo: Basit bir Windows Forms uygulamam var (C #, .NET 4.0, Visual Studio 2010). Çoğu diğer formun miras aldığı birkaç temel formu vardır, veritabanı erişimi için Entity Framework (ve POCO sınıfları) kullanır. Hiçbir şey fantezi, çoklu iş parçacığı veya başka bir şey yok.

Sorun: Hepsi bir süre iyiydi. Sonra, uygulamayı başlatmak üzereyken, tüm mavi, Visual Studio inşa başarısız oldu. Ben uyarı var "Silme dosyaya '... bin \ Debug \ [ProjeAdı] .exe' yoluna. Erişim engellendi '[ProjeAdı] .exe ... Bin \ Debug \' edilemiyor." ve "obj \ x86 \ Debug \ [ProjectName] .exe 'dosyası' bin \ Debug \ [ProjectName] .exe 'dosyasına kopyalanamıyor. İşlem' bin \ Debug \ [ProjectName] .exe dosyasına erişemiyor “çünkü başka bir işlem tarafından kullanılıyor.” (Yeniden oluştururken hem uyarı hem de hata alıyorum, ancak yalnızca Build çalıştırılırken hata alıyorum - bunun önemli olduğunu düşünmüyor musunuz?)

Uyarı ve hata mesajının söylediklerini gayet iyi anlıyorum: Visual Studio açıkçası exe dosyasının üzerine yazmaya çalışırken aynı zamanda bir sebepten dolayı bir kilit var. Ancak, bu soruna bir çözüm bulmama yardımcı olmuyor ... Çalıştığım tek şey Visual Studio'yu kapatıp yeniden başlatmak. Daha sonra bazı formlarda değişiklik yapana kadar bina ve lansman işe yarar, o zaman yine aynı problemim var ve yeniden başlatmak zorundayım ... Oldukça sinir bozucu!

Yukarıda bahsettiğim gibi, bu bilinen bir sorun gibi görünüyor, bu nedenle birçok önerilen çözüm var. Burada zaten denediklerimi listeleyeceğim, böylece insanlar neyi atlayacağını biliyorlar:

  • Yeni bir temiz çözüm oluşturmak ve sadece eski çözümden dosyaları kopyalamak.
  • Aşağıdakilere projenin derleme öncesi etkinliğine eklenmesi:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
  • Proje özelliklerine (.csproj dosyası) aşağıdakileri ekleme:

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Ancak, hiçbiri benim için çalışmadı, muhtemelen neden biraz sinirli olmaya başladığımı görebilirsiniz. Başka nereye bakacağımı bilmiyorum, umarım birisinin bana verecek bir şeyi vardır! Bu VS'de bir hata mı ve eğer varsa bir yama var mı? Yoksa yanlış bir şey mi yaptım, dairesel bir referansım veya benzeri bir şey var mı, eğer öyleyse nasıl öğrenebilirim?

Herhangi bir öneri son derece takdir :)

Güncelleme: As açıklamada aşağıda belirtilen, ben de aslında o Process Explorer ile kontrol ettim olduğunu dosyasını kilitliyor Visual Studio.


4
Uygulamanızın düzgün kapanıp kapanmadığını kontrol ettiniz mi? Görev yöneticisi [ProjectName] .exe dosyasını işlem listesinde gösteriyor mu?
miensol

2
Daha önce bunu yaşadım ve sadece dosyayı .old vb. Olarak yeniden adlandırdım ve yapıyı yeniden çalıştırdım. Tam olarak bildiğim bir düzeltme değil, ama benim için çalıştı.
36'da kodlayıcı

@miensol: Evet, düzgün bir şekilde kapanıyor gibi görünüyor. "[1848] [ProjectName] .vshost.exe: Managed (v4.0.30319) 'programından 0 (0x0) koduyla çıktım." @Barry: bin \ Debug'daki exe dosyasını yeniden adlandırmak işe yarıyor, ancak dediğin gibi bu gerçekten bir çözüm değil ve her seferinde yapmak oldukça can sıkıcı olacak. Yine de Visual Studio'yu yeniden başlatmaktan biraz daha iyi ...
Julian

2
@Naliluj: Bu makaleye, kaynak dosyalarıyla ilişkili olabileceğini açıklayan bir Microsoft forumundan geldim . Resx dosyaları kullanıyorsanız, bu bir ipucu verebilir.
Patrick

1
Posterity için bu sorun vardı ve benim csproj dosyasına <GenerateResourceNeverLockTypeAssemblies> true </GenerateResourceNeverLockTypeAssemblies> öğesi eklenerek çözüldü.
ThisIsTheDave

Yanıtlar:


117

Bu aptalca gelecektir, ancak VS2010'u Windows 7'de çalıştıran tüm bu çözümleri denedim. Hiçbiri yeniden adlandırmak ve en az söylemek çok sıkıcı olan bina dışında çalıştı. Sonunda suçluyu takip ettim ve inanmakta zorlanıyorum. Ancak AssemblyInfo.cs içinde aşağıdaki kodu kullanıyordum ...

[assembly: AssemblyVersion("2.0.*")]

Bu oldukça yaygındır, ancak bazı nedenlerden dolayı sürümü 2.0.0.0 olarak değiştirmek, işlerin tekrar çalışmasını sağlamıştır. Windows 7'ye özgü bir şey olup olmadığını bilmiyorum (sadece 3-4 hafta boyunca kullanıyorum) veya rasgele mi, yoksa ne mi, ama benim için düzeltti. VS oluşturulan her dosya üzerinde bir tutamacı tutuyordu tahmin, bu yüzden bir şeyler artırmak için nasıl bilecek? Gerçekten emin değilim ve bunun daha önce olduğunu hiç görmedim. Ama eğer başka biri de saçlarını çekiyorsa, bir deneyin.


12
Bu çılgın bir fikir, size şunu vereceğim;) Daha da çılgın olan şey, aslında işe yarıyor gibi görünüyor! Bunu birkaç kez test ettim ve "2.0. *" Gibi bir derleme sürümünü kullanırken hatayı alıyorum, ancak bunun yerine "2.0.0" ı kullandığımda bir cazibe olarak çalıştığını doğrulayabilirim! Daha fazla insanı bunu test etmeye çağırıyorum ve eğer işe yaradığını görürseniz lütfen bu cevabı oylayın, çünkü bu bilinmesi gereken bir şey! Umarım Microsoft bunu alır ... Teşekkürler drharris :)
Julian

2
Bu benim için işe yaramadı, VS'yi yeniden başlattığımda bazen hata alamadım. Bu hatayı her aldığımda VS 2010'u yeniden başlatmam gerekiyor
Sharique

6
fyi ... bu benim için işe yaramadı. Ayarlarım her zaman şöyle olmuştur: [assembly: AssemblyVersion ("1.0.0.0")] [assembly: AssemblyFileVersion ("1.0.0.0")]
tbone

4
Şu anda [assembly: AssemblyVersion ("1.0.0.0")] varsa, bunu [assembly: AssemblyVersion ("2.0.0.0")] ile değiştirin (yani '1' yerine '2'). Benim için çalıştı. Kontrol etmeme rağmen, sürümü şimdi sahip olduğunuzdan başka bir şeyle değiştirmeniz bu sorunu çözebilir.
Frederick The Fool

1
Çok dll için çalışıyor! VS dll kopyalayamaz diyor ve BOTH [assembly: AssemblyVersion] ve [assembly: AssemblyFileVersion ()] 1.0. * 2.0.0.0.0 değiştirdikten sonra çalıştı.
AZ.

14

Bu konuda daha fazla geri bildirim almadığım için, çözümüm olan şeyi paylaşacağımı düşündüm:

Barry'nin orijinal yayına yaptığı bir yorumda önerildiği gibi, '... bin \ Debug [ProjectName] .exe' dosyasını başka bir şeye manuel olarak yeniden adlandırmak (örn. '[ProjectName] 1.exe' ) bir çözümdür (I ' m ancak dosyayı kendim silmek için izin verilmiyor ve ben aynı kilit silinmeyi önleyen de yeniden adlandırma önleyeceğini inanıyorum gibi biraz garip buluyorum söylemek gerekir ...). İyi bir çözüm değil, ama makul hızlı (en azından birkaç kez yaptıktan sonra, neredeyse bir rutin haline geliyor) ve en azından başlangıçta yaptığım şey olan Visual Studio'yu yeniden başlatmaktan daha hızlı.

Birisi merak ederse, bu sorunu sadece yarı rastgele gördüğümü de ekleyebilirim. Genellikle bir formun tasarım modunda bazı değişiklikler yaptıktan sonra olur (ancak her zaman değil). Genellikle sadece iş-mantık kodunu veya görsel olmayan ilgili kodu değiştirirsem olmaz (ama bazen değişir). Gerçekten sinir bozucu, ama en azından benim için çalışan bir kesmek var - umarım bir sonraki projem de bu problemle yüzleşmez ...

@Barry: Yorumunuz için kredi almak istiyorsanız, lütfen bir cevap olarak yayınlamaktan çekinmeyin ve kabul ettiğinizden emin olacağım :)


Geçmişte yaptığım şey olduğu için buna oy verdim. Katılıyorum, kirli bir çözüm ama işe yarıyor. VS bu sorunu birkaç tekrar için yaşamıştır. Projemi de bir ağ dizininden yüklüyorum. Tamamen güvenilirdi, ama önemli değil. Bir sürücü eşlemesi mi yoksa bir UNC mi olduğu önemli değil. Evet, MS'in bunu düzeltmesi gerekiyor. Yeniden üretilemediğini söyleyen kapalı bir böcekleri var. Topal!
Josh Robinson

14

Basit bir çözüm buldum, sadece proje klasörü ve alt klasörler için Windows Dizin Oluşturma Hizmetlerini devre dışı bırakın


2
Bu benim için de işe yaradı. İşlem explorer devenv.exe kilitleme tutamacını gösterdiğini gösterdiğini neden anlamak emin değilim. Bununla birlikte, dizin oluşturmayı kapatmak sorunu çözdü.
Fopedush

1
@Fopedush Bu soruyu aynı çözümle karşılaştım, ancak o zaman bu soruyu görmedim. Bu cevabın neden yardımcı olduğuna dair bazı açıklamaları var.
Darren Hale

1
Bu benim için yaptı.
Martin Capodici

12

VS2008 (Windows 7 x32) WPF projesi ile aynı sorunu (MSB3021) var. Önceki çalıştırmadan sonra uygulamayı çok hızlı bir şekilde yeniden çalıştırmaya çalışırsam ortaya çıkan sorun. Birkaç dakika sonra kendi kendine kilidi exe dosyası ve ben uygulamayı yeniden çalıştırabilirsiniz. Fakat bu kadar uzun bir duraklama beni kızdırıyor. Bana gerçekten yardımcı olan tek şey VS'yi Yönetici olarak çalıştırıyordu.


1
Bu sorunla ilgili bu son hata raporunu buldum: connect.microsoft.com/VisualStudio/feedback/details/558848/… Bu hata raporu, hatayı yeniden üretebilen örnek bir proje sağladı. Drharris tarafından önerilen çözüm de orada çalıştı (örnek projeye adım adım çözüm için yukarıdaki bağlantıda belirtilen geçici çözüme bakın).
Julian

Benim için de işe yarayan tek çözüm bu. Teşekkürler @Nailuj!
Kanat

Bu, VS'yi yeniden başlatmaktan kesinlikle daha kolaydır.
Elvedin Hamzagic

1
Bağlantı sorunu için "sayfa bulunamadı", sadece utançtan silindi mi = S Bunun için yayınlanan bir çözüm / geçici çözüm var mı?
Coops

9

Bu sorunla karşılaştığımda, oluşturmaya çalıştığım projenin, nesnel klasördeki .exe'i kilitleyen çözümde Başlangıç ​​projesi olarak ayarlandığı gerçeği ile ilgilidir (ayrıca görev yöneticinizde de görünür) çözümünüzde başka bir projeye sağ tıklayın ve başlangıç ​​projesini ayarla'yı seçin. Bu, kilidi serbest bırakacak, görev yöneticisinden kaldıracak ve oluşturmanıza izin verecektir.


1
Bu benim için her zaman işe yarar. Hizmet için oluşturulan ve başlatılan vshost süreci ile ilgili gibi görünüyor
jaywayco

8

Buradaki cevaplardaki diğer tüm önerileri denedim, hiçbiri işe yaramadı. Sonunda VS2010 oluşturmak için başarısız benim .exe Sistem süreci (PID = 4) kilitli olduğunu keşfetmek için Process Monitor kullandım. SO'yu bunu içeren durumlar için aramak bu cevabı verdi .

Özetlendi: Uygulama Deneyimi hizmetini devre dışı bıraktıysanız (benim yaptığım gibi), yeniden etkinleştirin ve başlatın. İki yıllık şiddetlenme sona erdi.


+1 Daha önce başka her şeyi denedim (1. görev yöneticisi, 2. işlem gezgini yani pencerelerin bana izin vermediğini kapatın, 3. antivirüs devre dışı bırakma, 4. Windows Dizin Oluşturma hizmetinden APP_DATA / Local / Microsoft / Visual Studio hariç. ) ama bu ipucu yeniden: "Uygulama Deneyimi" hizmeti beni kafama duvara vurarak kurtaran tek hizmettir. Etkinleştirdim ve sorun ortadan kalktı. Komik şey, tekrar devre dışı bıraktıktan sonra her şey hala iyi oldu. Daha fazla sorun yaşamadım. Ama kesinlikle benim için ayıran tek şey bu.
Tomás

Benim için de çalış !!! İşe yarayan diğer tek şey de, uygulamayı çalıştırmadan önce bin klasörünü silmek , ancak çalıştırmadan önce her zaman silmeniz gerekir, çok can sıkıcı.
E_Blue

6

Ben de buna çok benzer bir sorun vardı ve benim durumumda bin \ debug klasörünü VMware ve VMware altında VMware, Explorer altında VM konuk altında veya hatta bir antivirüs altında paylaşılan bir klasör olarak kullanılabilir yapmamın nedenini buldum program altında (yüklü olduğunu sanmıyorum rağmen) dosya (lar) bir tutamacı tutuyordu.


Avast yüklü ve bu sabah benim dll içinde bir virüs olduğunu söyleyerek rastgele bir MVC hatası var. Hatadan sonra artık MVC projemi inşa edemedim. Avast Dosya Sistemi Kalkanı'na bir istisna ekledim ve her şey tekrar çalışıyor.
Tozlu

5

"Visual Studio barındırma işlemini etkinleştir" seçeneğini devre dışı bırak Proje Hata Ayıklama Ayarları


4

Process ExplorerDosyayı hangi işlemin kilitlediğini bulmak için indirmenizi öneririm . Şurada bulunabilir:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Kabul ediyorum - mutlaka dosyayı kilitleyen VS değil. Virüs denetleyicileri bundan suçlu olabilir. Bunun işe yarayıp yaramadığını görmek için virüs denetleyicinizi kapatmayı deneyin.
Polyfun

Üzgünüm, bunu zaten yaptığımı belirtmeyi unuttum. Ve dosya ([ProjectName] .vshost.exe) üzerinde kilit olan Visual Studio (devenv.exe) olduğunu söylüyor. Yani bu da bana pek yardımcı olmuyor.
Julian

@ShellShock: Anti virüsümü (Avast) devre dışı bırakmak da yardımcı olmuyor.
Julian

Benim için, Sysinternals ProcessExplorer kullanarak, bu dosya için bir tanıtıcı görebilirsiniz, ancak üzerine tıkladığımda, hiçbir uygulama onu tutan gösterilmez ve tanıtıcıyı kapatmaya çalıştığımda, "Hata açma işlemi: tanıtıcı geçersiz." ProcessExplorer'da hata. Yine de kilit hala devam ediyor.
tbone

4

Visual Studio'yu kullanarak, hatayı yeniden oluşturmak için asla basit bir proje bulamadım.

Benim çözüm Visual Studio Hosting işlemini devre dışı bırakmak oldu.

İlgilenenler için rahatsız edici tanıtıcı için bir tanıtıcı iz ekledim:

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

Sorunun en üstünde bir hata raporu ve hatayı yeniden üreten örnek bir proje ile Microsoft Connect'e bir bağlantı var: connect.microsoft.com/VisualStudio/feedback/details/558848/…
Julian

Barındırma sürecini devre dışı bırakmak benim için çalıştı. Yeniden etkinleştirdikten sonra da çalışmaya devam eder. Bu sorunu yüzlerce çözümü denemek için 4 saat harcadım. Uzaktan bile işe yarayan tek kişi bu.
Drew Chapin

4

SORUNUNUZ HEMEN ÇÖZÜLMEDİĞİNDE:

Visual Studio'nun hatası:

"İşlem 'bin \ Debug ** app.exe **' dosyasına erişemiyor çünkü başka bir işlem tarafından kullanılıyor."

Bu nedenle, pencerelerin görev yöneticisine (Ctrl + Shift + Esc) gidin, uygulama adınızı bulun ve Endprocces tarafından kapanmaya zorlayın.


3

İşte başka bir olasılık:

Vs2012 / win7'de bu hatayı aldıktan sonra, gittim ve bin dizinindeki dosyayı silmeye çalıştım ve explorer, dosyanın XAML UI Designer tarafından kullanımda olduğunu belirtti.

VS'de açtığım tüm sekmeleri kapattım, VS'yi kapattım, sonra taskmanager'deki tüm MSBuild işlemlerini öldürdüğümden emin oldum. Son olarak, VS'yi yeniden başlattıktan sonra çözümü oluşturabildim.


ve başka bir olası neden:

Bu sorunun başka bir olası nedenini fark ettim. Bazı kod yeniden düzenleme, projeleri bir çözümün içine ve dışına taşıdıktan sonra, proje referanslarım artık çözümdeki projelere beklendiği gibi referans vermiyordu.

Bu yanıltıcı görsel stüdyo, aynı anda bazı projeler inşa edebileceğini düşünerek dosya kilitleri yaratıyor.

EDIT: Bu son zamanlarda VS2012 ile bile birkaç kez oldu ve ben doğru sipariş bağımlılık kurmak için sipariş kurmak, VS çalışan bırakan herhangi bir msbuild süreçleri öldürmek ve sonra VS yeniden başlatın. Ben emin olmak için msbuild süreçleri öldürmek, ama VS kapatmak da onları öldürmek gerekir.

Bunun için genellikle yaptığım şey, bir projeyi, son derlemede referansta bulunmayan çözüm içindeki başka bir projeye dayanacak şekilde yeniden düzenleyen bir projedir. Bu bazen VS'yi karıştırıyor gibi görünüyor ve oluşturma sırasını güncellemiyor.

Derleme sırasını denetlemek için: Çözüm Gezgini'nde Çözümü sağ tıklatın ve "Proje Derleme Sırası ..." seçeneğini seçin ve bağımlılıkların her proje için uygun şekilde not edildiğini doğrulayın.


Son zamanlarda bunu bir WinPhone 8 projesinde deneyimledik. Açıklanamayan, bunun nedeni Tuple tipini kullanmaktı. Bir Tuple kullanılan kodu kaldırmak sorun ortadan kalktı. Kodu döndürülen sorunu geri ekleyin.
Seamus

VS2012 ile aynı sorunu vardı, VS kapatmak hile yapmadı - elle tüm msbuild.exe görevleri öldürmek zorunda
mizzle

Ben VS 2013 kullanıyorum ve sadece her yapı öncesi görev yöneticisi "XDesProc.exe * 32" işlemini (Microsoft Visual Studio XAML UI Tasarımcısı) öldürmek mümkün oldu ve bu hile yaptı. XAML UI tasarımcısı, tasarım görünümünde * .xaml dosyasını her açışınızda yeniden yüklendiğinden VS'yi yeniden başlatmanıza gerek yoktur.
Tim Sexton

3

IIS'yi yeniden başlat - hata ayıklayıcıya eklenmiş bir işlem olabilir


3

Virüsten koruma programını devre dışı bırakın ve deneyin. Ben de bu sorunla karşı karşıyaydım ... ama benim durumumda antivirüs, antivirüs devre dışı bırakıldığında benim uygulamayı engelliyordu çözüldü.


3

Aynı hatayla karşılaştım.

Tüm bağımlı proje / kütüphanelerin bin klasörlerinin tüm içeriğini silerek sorunu çözdüm.

Bu hata çoğunlukla sürüm değişiklikleri nedeniyle oluşur.



1

Önce basit şeyleri yapın.

Çözümünüzün bir bölümünün çalışan bir işlem tarafından kilitlenip kilitlenmediğini kontrol edin.

Örneğin, Windows kurulumumda "InstallUtil 'komutunu çalıştırdım (normalde bir konsoldan test yapıyorum).

Bu windows hizmet projesinin bin klasöründe benim dll bazı kilitli. Bir yeniden inşa ettiğimde, bu konuda istisna aldım.

Windows hizmetini durdurdum, yeniden inşa ettim ve başarılı oldu.

Bu sorundaki ileri adımlardan herhangi birini yapmadan önce Uygulamanız için Windows Görev Yöneticisi'ne bakın.

Bu yüzden ayak sesleri duyduğunuzda, atların zebralar olmadığını düşünün! (tıp öğrencisi arkadaşından)


1

Aynı problemim vardı. Bin \ debug obj için kopyalanamadı dedi .....

Ne zaman web proje oluşturmak benim dll tüm bin \ debug değil bin klasöründe bulundu. Yayınlama sırasında vs bin \ debug dosyaları arıyordu. Bu yüzden editörde web proje dosyasını açtım ve bin \ debug örneklerini arayın ve tüm dll'nin bin \ debug \ mylibrary.dll olarak belirtildiğini gördüm. Tüm \ debug'u yoldan kaldırdım ve tekrar yayınladım. Bu kez vs bin klasöründeki tüm dll bulabildi ve yayın başarılı oldu.

Web proje dosyasında bu yolun nasıl değiştiğine dair hiçbir fikrim yok.

Bunu hata ayıklamak için 5 saatten fazla zaman harcadım ve sonunda kendi başıma çözüm buldum.

Bu doğru cevap .


1

Yukarıdakilerin hiçbiri işe yaramazsa ve bir konsol uygulaması geliştiriyorsanız:

Program.cs dosyasına herhangi bir karakter yazmayı deneyin ve ardından silin. Bunun neden çalıştığı hakkında hiçbir fikrim yok, ancak her seferinde 'Kopyalanamıyor' sorununu çözüyor gibi görünüyor.


1

Bu daha çok Avast'tan kaynaklanır.

Projelerimi genellikle Release'de çalıştırabilirim, ancak hata ayıklamada çalışırken oldukça düzenli olarak başarısız olur.

Sadece projelerim klasörü için bir dışlama ekliyorum ve sorun ortadan kalkıyor gibi görünüyor. Bunun diğer antivirüs yazılımlarından da kaynaklandığını düşünüyorum.


1

.Exe ve .pub dosyasını yeniden adlandırmak benim için çalıştı, ama gerçekten sıkıcı. Ayrıca hata ayıklama oturumu sırasında düzenleme yapamadığım bir sorunla karşılaşıyorum. Son olarak, Gelişmiş Güvenlik Ayar Sayfasına gittim:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION % 3dV4.0% 22% 29 & rd = true

"ClickOnce güvenlik ayarlarını etkinleştir" onay kutusunun işaretini kaldırıp yeniden seçiyorum. Birkaç gündür sorunsuz oldu ....


1

Benim için bunun nedeni, hedef klasörde bir komut isteminin açık olmasıydı (C:\users\username\source\repos\project\project\bin\debug\app.publish ) .

DEBUGGING'in neden yayınlama klasörüne erişim gerektirdiğinden emin değilim, ancak komut penceresini kapatmak sorunu benim için çözdü.


1

Birisinin Birim Testi hata ayıklamaya veya birim testi çalıştırmaya çalışırken buna girmesi durumunda, dosyayı serbest bırakabilmesi için aşağıdaki iki işlemi öldürmek zorunda kaldım:

öldürme süreçleri.


0

Sağladığınız birkaç çözümü denedim, ancak bazen bu hatayı alıyorum. İşlemimin çalışmadığından eminim ve Internet Explorer ile yürütülebilir dosyayı silmeye çalıştığımda dosya listesinden kaldırıldı, ancak daha sonra F5 ve voila'ya basıyorum, dosya geri döndü. Hiç silinmedi.

Ancak TotalCommander üzerinden dosyayı silersem, exe dosyası gerçekten silinir ve projeyi başarıyla oluşturabilirim.

Windows 7 x64 ve toplam komutan 7.56a 32 bit kullanıyorum.


0

Diğer yanıtların hiçbiri benim için çalışmadı, ancak Visual Studio'daki tüm açık sekmeleri kapatmak sorunu çözmüş görünüyor.


0

Bunun çok eski bir soru olduğunu biliyorum, ancak son zamanlarda VS 2012'de "obj'den bin'e kopyalayamıyorum" hatasını yaşadım. Belirli bir projeyi yeniden oluşturmaya çalıştığımda her mesajımı aldım. Tek çözüm, her yeniden inşa etmeden önce bir temizlik yapmaktı.

Çok araştırma yaptıktan sonra, dosyalarımdan birinde derlemenin başarılı olmasını engellemeyen, ancak bir şekilde VS'yi dosyaları kilitli tutmaya karıştıran bir pragma uyarı ifadesi vardı.

Benim durumumda, dosyanın üst kısmında şunlar vardı:

#pragma warning(

Bu kadar. Sanırım bir süre önce bir şeyler yapmaya çalışıyordum ve dikkati dağılmıştı ve süreci hiç bitirmedim, ancak bu hatla ilgili VS uyarıları karışıklıkta kayboldu. Sonunda uyarıyı fark ettim, hattı kaldırdım ve o zamandan beri her seferinde yeniden inşa ettim.


0

Benzer bir sorunla karşılaştığımda işe yarayan tek şey şuydu:

  • Projeye sağ tıklayın, Ayarlar'a gidin ve hem Debug hem de Release sürümlerinin aynı ayarları hedeflediğinden emin olun ya da uygulamada yüklemeye veya kaydetmeye çalıştığınız ayarlara sahip olun.
  • C: \ Users (KullanıcıKullanmanızAccount) \ AppData \ Local (UygulamaAdınız) klasörünü silme.
  • Orada hiçbir dosya "Engellendi" olarak kabul edildiğinden emin olmak. Projemin içerdiği dosyaları sağ tıklatarak, bir simgenin aslında internetten indirildiği için engellendiğini ve kötü olduğunu düşündüm. Engellemeyi kaldır düğmesini tıklatmak zorunda kaldım (örneğin, şunu kontrol et: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Bu dosya başka bir bilgisayardan geldi ve yardım etmesi engellenmiş olabilir bu bilgisayarı koru. ").

0

WCF kullanan Windows Hizmetleri için, WFC ana bilgisayar işlemini sonlandırdım ve işe yaradı. Bu olduğunda nefret ediyorum ve bazen rastgele oluyor.


0

Çözümümün sürümler, kilitlenen işlemler, dosyaları yeniden başlatma veya silme ile ilgisi yoktur.

Sorun aslında derlemenin başarısız olması ve doğru hatayı vermemesiydi. Asıl sorun bir tasarım hatasıydı:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

"A" nın kapsamını fonksiyonun dışına değiştirdikten veya "a" kullanmadan sonra Task.Factory.StartNew();tekrar yapılandırabildim.

Bu, Windows7x64 sp1'de VS2012 Güncelleştirme 4 kullanıldığında oldu.

Hata mesajı:

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (3390,5): hata MSB3030: Bulunamadığı için "obj \ x86 \ Debug \ xxx.exe" dosyası kopyalanamadı .


0

VS2013 ile buldum Bu hatayı düzenli olarak alıyorum. Oldukça iyi işleyen bir şey, uygulamayı çalıştırmaya çalışmadan önce bir Yeniden Oluşturma Çözümü yapmaktır. Bir TEMİZ gerçekleştirmenin bazen işe yaradığını gördüm, ancak Yeniden Oluşturma Çözümü daha tutarlı çalışıyor gibi görünüyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.